> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_20/session_05_campaign_dag_recovery.md). # Session 05: Campaign DAG Recovery **Session ID**: `phase20-session05-campaign-dag-recovery` **Packages**: `packages/protocol`, `apps/server`, `apps/web` **Status**: Not Started **Estimated Tasks**: \~12-25 **Estimated Duration**: 2-4 hours *** ## Objective Execute campaign tasks in dependency order and give operators truthful retry and recovery controls. *** ## Scope ### In Scope (MVP) * Treat campaign tasks as a DAG and execute ready tasks serially in dependency order. * Block dependent tasks until prerequisites finish successfully. * Mark campaign state as in progress, completed, blocked, failed, or unavailable from actual task outcomes. * Add retry for failed or unavailable executable tasks while preserving idempotency and previous run history. * Add cancel or hold behavior for remaining queued tasks when a required dependency fails. * Display campaign graph execution states, dependency blocks, retries, and execution detail links. ### Out of Scope * Parallel campaign orchestration. * New executor families beyond the payloads already supported by earlier sessions. *** ## Prerequisites * [ ] Session 04 completed and validated. * [ ] Campaign dependency and retry acceptance tests defined before implementation starts. *** ## Deliverables 1. Campaign scheduler behavior, retry/recovery behavior, state semantics, UI graph updates, and tests. 2. Evidence that campaign completion reflects actual execution and dependency state. *** ## Success Criteria * [ ] Task B cannot run before required task A completes. * [ ] A failed or unavailable task blocks dependents and prevents false campaign completion. * [ ] Retry reruns only failed or unavailable executable tasks. * [ ] Campaign state mirrors the actual execution and dependency state. * [ ] Browser e2e proves the operator can inspect and retry a failed campaign task. *** ## Folded Source Detail ### User Outcome A campaign with executable tasks dispatches runnable work in dependency order, records each execution, marks task and campaign outcomes truthfully, and lets the operator retry failed tasks. ### Required Changes * Treat campaign tasks as a DAG. Initial implementation can execute serially in dependency order; do not claim parallel orchestration until concurrency is implemented and tested. * Skip tasks without executable payload and mark them blocked or keep them pending with a planning-only reason. * Dispatch ready executable tasks only after dependencies finish successfully. * Mark campaign `completed` only when all dispatchable executable tasks completed and required verification passed. * Mark campaign `failed`, `blocked`, or `unavailable` on failed, dependency blocked, or unavailable tasks. * Include `executions` in campaign responses. * Add `retryFailed()` behavior that re-dispatches only failed or unavailable executable tasks while preserving idempotency and previous run history. * Queue rows created from campaign tasks should carry the same executable payload and link back to campaign/task ids. ### Recovery Paths * Retry failed task. * Cancel remaining queued tasks. * Mark planning-only tasks as non-dispatchable. * Inspect execution detail for each task. * Create follow-up rollback executable for Git or file tasks when available. ### State Semantics * Campaign is `in_progress` while any executable task is running or queued. * Campaign is `completed` only when all dispatchable executable tasks finished and required verification passed. * Campaign is `blocked` when dependencies or approvals block progress. * Campaign is `failed` when one or more required executable tasks failed and no retry is currently in flight. ### Acceptance Tests From Findings * Campaign route test proves create -> approve -> dispatch -> task execution runs -> campaign completed. * Dependency test proves task B does not run before task A completes. * Failure test proves dependent tasks are blocked and retry only reruns failed tasks. * Campaign state mirrors actual execution and dependency state. * Web test proves campaign graph displays per-task execution states and links. * Browser e2e proves the operator can inspect and retry a failed campaign task. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_20/session_05_campaign_dag_recovery.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.