Resume a paginated snapshot from the last committed page
The importer crashes on page four and restarts from page one, occasionally skipping records because the cursor is saved before page writes finish. Couple the checkpoint to the page commit.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Transactions · Cursor pagination · Idempotency · Recovery
Estimated field mix
- Integrations40%
- Database engineering40%
- Data 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 retailer receives stock from two vendor warehouses. The vendor API paginates snapshots and emits change events, but retries and deleted products have caused unexplained stock drift. Work against a local vendor simulator.
Setup prerequisites
- Create a local vendor API simulator with cursor pages and stock events.
- Use synthetic tenants, SKUs, and warehouse records; no vendor account is required.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- A page and its next cursor commit atomically within one tenant-scoped transaction.
- Replaying a committed page is idempotent by snapshot and record identity.
- Expired cursors leave the current attempt incomplete and start a separately identified snapshot rather than mixing pages.
Implementation constraints
- Store snapshot identity alongside opaque vendor cursors.
- Do not infer cursor order from cursor text.
Verification to include
- Inject a failure between page writes and checkpoint and verify neither commits.
- Resume after a successful page commit and assert no missing or duplicate stock records.
Deliverables
- Transactional snapshot checkpointing and restart scenarios
Rollout and recovery
Run an initial snapshot in shadow storage; activate only a fully completed snapshot version.
Value of the work
For the engineer: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure.
For the team: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path.
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.