Terry Pipeline Lifecycle

Canonical Flow

Reference pipeline для Terry:

source -> ingest -> validate -> normalize/transform -> persist -> notify -> retry/dead-letter

Stages

1. Ingest

• job получает данные из source;
• raw payload сохраняется в execution context;
• transport/runtime ошибки помечаются отдельно от бизнес-ошибок.

Current baseline:

• universal loader activity стартует по data_source_id, а не по inline transport config;
• activity сначала резолвит persisted LoaderConfig из catalog-а Terry;
• middleware вроде fingerprint/incremental/proxy/rate-limit собираются из persisted config автоматически.

2. Validate

• применяются schema checks, required field checks и domain rules;
• каждая validation rule возвращает machine-readable result;
• pipeline решает, можно ли продолжать обработку, частично пропустить record или завершить batch ошибкой.

3. Normalize / Transform

• входной payload приводится к normalized record;
• выполняются mapping, coercion, enrichment и canonical naming;
• на выходе формируется стабильный internal contract для sink и notifications.

4. Persist

• запись в sink должна быть идемпотентной;
• raw payload, normalized record и processing metadata желательно разделять;
• outcome должен позволять понять, что было создано, обновлено, пропущено или отбраковано.

5. Notify

• notification rules анализируют pipeline outcome;
• notification template рендерится на основе normalized data и execution metadata;
• доставка выполняется в один или несколько delivery channel.

6. Retry / Dead-Letter

• временные инфраструктурные ошибки должны ретраиться;
• детерминированные contract/validation ошибки не должны бесконечно повторяться;
• batch или record, который не удалось обработать, должен попадать в dead-letter flow с полным context.

Failure Semantics

Нужно различать как минимум четыре класса результата:

• success — record обработан и сохранён;
• rejected — record признан невалидным по rule/policy;
• retryable_failure — временная ошибка чтения, сохранения или доставки;
• dead_lettered — исчерпаны retry policy или найден non-recoverable defect.

Traceability

Каждый pipeline run должен иметь:

• job_id;
• run_id;
• source metadata;
• timestamps по стадиям;
• status каждой стадии;
• ссылки на сохранённые payloads и delivery attempts.

Текущее состояние реализации покрывает только начало этой трассировки:

• известны workspace_id, domain_id, data_source_id, page_type и code_name;
• эти identifiers уже пробрасываются как runtime metadata universal loader output;
• job_id, run_id, persisted execution history и delivery attempts ещё не реализованы.