Files

T

ddadminandClaude Opus 4.6 a207f8d281 docs(testing): усилены инструкции по управлению DAG через REST API

- Зачем:
  - агент использовал CLI (`docker exec ... airflow dags unpause`) вместо REST API,
    что приводило к зависанию DAG'ов в статусе `queued`.
- Что:
  - e2e-etl-test-protocol: явный запрет на CLI-команды, REST API как основной метод,
    шаблон unpause+trigger для каждого слоя, пример проверки статуса через API.
  - agent-dag-testing: убрана оговорка «если он новый» — unpause обязателен всегда.
  - TODO: пункт «стенд поднимается на чистой машине» отмечен выполненным.
- Проверка:
  - прочитать docs/e2e-etl-test-protocol.md и docs/agent-dag-testing.md.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-09 20:50:39 +03:00

4.3 KiB

Raw Blame History

Тестирование DAG (гайд для AI-агентов)

Этот документ описывает, как агенту взаимодействовать с Airflow (без UI) для точечной проверки и отладки DAG'ов в процессе разработки.

0. Состояние среды (Предварительная проверка)

Прежде чем тестировать DAG, убедитесь, что стек работает:

docker compose ps

Если контейнеров нет, поднимите стек: make up. Если исходная база данных пуста (например, после make clean), проинициализируйте её: make bookings-init.

1. Быстрая проверка структуры графа (Локально)

При любом изменении Python-кода DAG'а сначала проверьте, что он компилируется и структура графа корректна:

make test

Это запустит smoke-тесты (tests/test_dags_smoke.py), которые проверят целостность всех DAG'ов без обращения к базе данных.

2. Запуск конкретного DAG'а (REST API)

Для тестирования загрузки данных запустите измененный DAG через REST API (базовый URL http://localhost:8080/api/v1, креды взять из .venv).

Шаг 2.1. Снять DAG с паузы (при старте стенда все DAG'и на паузе — этот шаг обязателен!):

curl -s -X PATCH "http://localhost:8080/api/v1/dags/<dag_id>" \
  -u admin:admin -H "Content-Type: application/json" -d '{"is_paused": false}'

Шаг 2.2. Запустить DAG:

curl -s -X POST "http://localhost:8080/api/v1/dags/<dag_id>/dagRuns" \
  -u admin:admin -H "Content-Type: application/json" -d '{}' | jq '{dag_run_id}'

Шаг 2.3. Проверить статус выполнения: Используйте dag_run_id из предыдущего шага:

curl -s "http://localhost:8080/api/v1/dags/<dag_id>/dagRuns/<dag_run_id>" \
  -u admin:admin | jq '{state}'

Повторяйте запрос, пока state не станет success или failed.

3. Отладка упавших задач

Если DAG перешел в статус failed, найдите упавшую задачу:

Шаг 3.1. Получить статусы всех задач:

curl -s "http://localhost:8080/api/v1/dags/<dag_id>/dagRuns/<dag_run_id>/taskInstances" \
  -u admin:admin | jq '.task_instances[] | {task_id, state}'

Шаг 3.2. Посмотреть логи упавшей задачи (через CLI Airflow): REST API отдает логи сложно, поэтому для логов проще использовать docker compose exec:

docker compose exec airflow-webserver airflow tasks logs <dag_id> <task_id> <run_id>

(Совет: ищите в логах слова ERROR, Exception или вывод SQL-ошибок от PostgresOperator).

4. Проверка результата в DWH (Greenplum)

Успешное выполнение DAG'а (зеленый статус) не гарантирует, что данные загрузились правильно (например, если источник был пуст). Проверьте целевые таблицы напрямую:

docker compose exec greenplum bash -lc "su - gpadmin -c \"/usr/local/greenplum-db/bin/psql -t -A -d gp_dwh -c 'SELECT COUNT(*) FROM <схема>.<таблица>;'\""

Убедитесь, что таблица содержит ожидаемое количество строк.

5. Полный сквозной тест (E2E)

Если вы вносили масштабные изменения, затрагивающие несколько слоев DWH, или меняли DDL таблиц, рекомендуется прогнать полный конвейер (STG -> ODS -> DDS -> DM):

make e2e-etl

Этот скрипт сам запустит все нужные DAG'и в правильном порядке и проверит результаты.

4.3 KiB Raw Blame History Unescape Escape