Справочник: стейт-машина сессии¶

Session отслеживает две вещи независимо: где она в пайплайне (current_stage) и как у неё дела (health). Это разделение и есть причина, почему сессия может быть на стадии checked и при этом быть blocked из-за ошибок, или ready к подтверждению.

Стадии¶

current_stage проходит:

CREATED → UPLOADED → PARSED → TRANSFORMED → VALIDATED → CONFIRMED → APPROVED → EXPORTED

Автоматические стадии — parsed, transformed, checked — продвигаются только при исходе passed или warnings. При errors стадия не продвигается, чтобы можно было исправить и перезапустить с места остановки.
Ручные стадии — confirmed, approved, exported — продвигаются при действии всегда, независимо от исхода.

Исходы стадий¶

Каждая стадия фиксирует исход в посводке по стадии:

Исход	Значение
`pending`	Не начата.
`running`	В процессе.
`passed`	Завершена чисто.
`warnings`	Завершена с предупреждениями.
`errors`	Провалена; блокирует прогресс.

По каждой стадии сессия хранит outcome, error_count, warning_count и таймстамп updated_at — это и управляет постадийной раскраской в UI.

Необязательные sources и пропущенная работа¶

Когда source у DataContract необязательна и не доставлена, трансформер, зависящий только от неё, помечается SKIPPED, а не падает. Пропущенный трансформер считается разрешённым, поэтому стадии transformed и checked всё равно достигают passed, а health может стать ready. При экспорте отсутствующая необязательная source перечисляется под omissions в datapackage.json и в export_report сессии. Отсутствие обязательной source по-прежнему даёт errors.

Health¶

health выводится из стадий и текущей стадии — никогда не ставится напрямую. Вывод в порядке приоритета:

current_stage == exported → completed
любой исход стадии errors → blocked
любой исход стадии running → in_progress
любой исход стадии warnings → attention
current_stage в (checked, confirmed, approved) без ошибок/предупреждений → ready
стадий ещё нет → created
иначе → in_progress

То есть: одна ошибка где угодно делает всю сессию blocked; предупреждения без ошибок — attention; чистый проход через валидацию — ready к подтверждению.

Перезапуск заблокированной сессии¶

blocked запрещает сессии двигаться вперёд, но не запрещает перезапуск. Пока сессия не подтверждена, run, transform и check можно запустить повторно, в том числе на сессии в checked, у которой упали бизнес-правила. После исправления бизнес-правила, правила Entity, маппинга трансформера или каталога: run (или check) на сессии в checked заново гоняет валидацию Entity и бизнес-правила; transform на сессии в transformed или checked повторяет с трансформации. Сессия откатывается на стадию перед повторяемой (checked → transformed, transformed/checked → parsed), пока новый прогон не запишет свой исход; каждый запуск ложится отдельным прогоном в историю прогонов. Пока упавшая стадия выполняется заново, сессия остаётся blocked (её запись стадии — running с previous_outcome: errors); блок снимается только когда новый прогон завершится чисто, и возвращается, если он снова упадёт. confirm, approve и export по-прежнему закрыты.

Почему это важно при разборе¶

Когда вы открываете список Sessions, колонка health говорит, что требует действия (blocked / attention) против того, что движется или готово. Стадия говорит, как далеко ушла каждая поставка. Вместе они позволяют триажить много поставок одним взглядом, не открывая каждую.