Backfill the window a failed job skipped
A gap left by a failed job, filled with counts reconciled and the rerun proven idempotent.
The ticket
Backfill the window a failed job skipped and reconcile the result.
Acceptance criteria
- The gap is identified precisely before anything runs
- Row counts are reconciled against the source
- Running the backfill twice does not duplicate rows
- Downstream models are refreshed after the backfill
What lands as proof
Reconciled counts against the source, plus a demonstration that a second run changes nothing.
Why teams defer it
- A backfill that is not idempotent turns a gap into duplicates, which is harder to fix than the gap.
- Downstream models cache the gap, so refreshing them is part of the job and easy to forget.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: backfill the window a failed job skipped and reconcile the result. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means row counts before and after, the rerun proven idempotent, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops for the plan, and the review bar is raised afterwards so that smaller suggestions block the merge too, not only serious findings.