Временные пробы
Временная проба проверяет отложенный или асинхронный эффект: «сделай X — и в течение N секунд произойдёт Y». Она закрывает то, что обычные тесты покрыть не могут — всё, что происходит позже, вне ответа:
- асинхронный воркер обрабатывает заказ после того, как API уже ответил
202; - webhook приходит на ваш эндпоинт через несколько секунд после события;
- eventual consistency — запись становится видимой на другом пути чтения;
- cron / плановая задача даёт результат по своему расписанию;
- повтор с backoff в итоге завершается успешно;
- консьюмер очереди забирает сообщение и применяет изменение.
Вместо хрупкого фиксированного sleep проба опрашивает до срабатывания — и сообщает фактическую задержку (сколько времени эффект добирался), что само по себе полезная метрика.
Из чего состоит проба
Три стадии:
- Триггер (необязательно) — действие, запускающее асинхронный процесс.
httpвыполняет запрос (напр.POST /orders); без триггера проба просто наблюдает за уже идущим эффектом (cron, внешние события). - Ожидание — стратегия опроса:
intervalMs(по умолчанию 1000),timeoutMs(по умолчанию 30000, максимум 30 минут), необязательныйbackoff(linear/exponential), необязательныйminStableChecks(N подряд успешных проверок — защита от «дребезга»). - Проверка — что подтверждает эффект:
http— опрашивать эндпоинт, пока ответ не совпадёт (expectStatus,bodyContains,jsonPath+equals);store— ключ Global/Chain-хранилища содержит ожидаемое значение (или существует);mock_hit— мок получил подходящий запрос — проверка доставки webhook.
Результат — отчёт: вердикт fired / timeout / error, latencyMs (время до срабатывания), число попыток, последнее наблюдённое значение и полная трасса по попыткам. Если адрес проверки на каждой попытке отвечает 401 или 403, вердикт — error с пояснением, что в доступе отказано: ничего не измерено, поэтому это не выдаётся за медленный эффект. Передайте проверке заголовки, нужные для входа.
В интерфейсе
Временные пробы в боковом меню → соберите три стадии в форме, Запустить, читайте вердикт и таймлайн трассы. У сохранённых проб хранится история запусков.
Через API
Разовая проба одним вызовом (при таймауте ≤ 60с готовый отчёт возвращается сразу):
curl -X POST "http://localhost:5770/api/v1/namespaces/my-namespace/temporal-probes/run" \
-H "X-API-Key: $TOKEN" -H "Content-Type: application/json" -d '{
"trigger": {"kind": "http", "http": {"method": "POST", "url": "https://api.example.com/orders", "body": "{\"item\":\"42\"}"}},
"wait": {"intervalMs": 1000, "timeoutMs": 30000},
"check": {"kind": "http", "http": {"url": "https://api.example.com/orders/last", "jsonPath": "$.status", "equals": "processed"}}
}'
При большем таймауте вызов вернёт 202 и запуск в статусе running — опрашивайте GET /temporal-probes/runs/{runId} до терминального вердикта.
Сохранённые пробы: POST /temporal-probes (тело {name, description, config}), GET /temporal-probes, POST /temporal-probes/{id}/run, GET /temporal-probes/{id}/runs.
Из AI-агента
MCP-инструмент temporal_probe_run выполняет весь цикл одним вызовом — триггер, опрос, отчёт. temporal_probe_create / temporal_probe_run_saved / temporal_probe_get_run управляют сохранёнными пробами и асинхронными запусками.
В тест-плане
Добавьте элемент temporal_probe со ссылкой на сохранённую пробу: шаг плана проходит, когда проба сработала, и падает (с полной трассой в отчёте шага) по таймауту — план может делать функциональный шаг → дождаться асинхронного эффекта → следующий шаг.
Проверка доставки webhook
- Создайте мок — приёмник webhook.
- Запустите действие, которое должно отправить webhook.
- Проверка
mock_hitс ID мока (опциональноmethod,pathContains,minCount) — проба срабатывает в момент, когда мок получает колбэк, аlatencyMsпоказывает, сколько заняла доставка.
Ограничения
Проба — ограниченный опрос: таймаут не более 30 минут, интервал не менее 250 мс, число попыток ограничено — проба никогда не превратится в бесконечный цикл повторов.