Recover an import after the queue acknowledgement is lost
The database commits an accepted batch and the API process exits before enqueueing reconciliation. The UI remains on Processing until someone runs SQL manually.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Outbox · Queue semantics · Failure recovery
Estimated field mix
- Distributed systems50%
- Backend30%
- Database engineering20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional subscription service invoices in USD and EUR. Finance currently compares a payment-provider CSV with database exports; late refunds and retried imports make the monthly close unreliable. Work on synthetic ledger entries only.
Setup prerequisites
- REST APIs
- SQL transactions
- Integer money representation
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Accepted batch and dispatch intent commit atomically.
- Restarted dispatch delivers pending work with a deterministic job identity.
- Repeated delivery produces the same reconciliation result without duplicate entries.
Implementation constraints
- Keep provider payloads out of queue metadata; use a durable batch identifier.
Verification to include
- Interrupt after database commit and recover through the dispatcher.
- Deliver the same job twice and compare the ledger and audit counts.
Deliverables
- Transactional dispatch path and crash-recovery reproduction
Rollout and recovery
Start dispatch in observe mode, then enable pending batches; pause dispatch to rollback without losing intent.
Value of the work
For the engineer: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary.
For the team: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.