Документация Временные пробы

Временные пробы

Временная проба проверяет отложенный или асинхронный эффект: «сделай X — и в течение N секунд произойдёт Y». Она закрывает то, что обычные тесты покрыть не могут — всё, что происходит позже, вне ответа:

  • асинхронный воркер обрабатывает заказ после того, как API уже ответил 202;
  • webhook приходит на ваш эндпоинт через несколько секунд после события;
  • eventual consistency — запись становится видимой на другом пути чтения;
  • cron / плановая задача даёт результат по своему расписанию;
  • повтор с backoff в итоге завершается успешно;
  • консьюмер очереди забирает сообщение и применяет изменение.

Вместо хрупкого фиксированного sleep проба опрашивает до срабатывания — и сообщает фактическую задержку (сколько времени эффект добирался), что само по себе полезная метрика.

Из чего состоит проба

Три стадии:

  1. Триггер (необязательно) — действие, запускающее асинхронный процесс. http выполняет запрос (напр. POST /orders); без триггера проба просто наблюдает за уже идущим эффектом (cron, внешние события).
  2. Ожидание — стратегия опроса: intervalMs (по умолчанию 1000), timeoutMs (по умолчанию 30000, максимум 30 минут), необязательный backoff (linear / exponential), необязательный minStableChecks (N подряд успешных проверок — защита от «дребезга»).
  3. Проверка — что подтверждает эффект:
    • 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

  1. Создайте мок — приёмник webhook.
  2. Запустите действие, которое должно отправить webhook.
  3. Проверка mock_hit с ID мока (опционально method, pathContains, minCount) — проба срабатывает в момент, когда мок получает колбэк, а latencyMs показывает, сколько заняла доставка.

Ограничения

Проба — ограниченный опрос: таймаут не более 30 минут, интервал не менее 250 мс, число попыток ограничено — проба никогда не превратится в бесконечный цикл повторов.