Checkpoint partial bulk progress

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Import 120 teaching records in chosen 50-item batches verified within current limits. Two batches confirm 100; batch three has five acknowledged, five failed and ten unknown. Do not restart everything or treat unknown as not written.

Mechanism

Keep a fixed inventory/stable identity and per-item confirmed/failed/unknown states plus continuation. Resume by reconciling checkpoint/external results: skip acknowledged work, handle known failures under contract and reconcile unknowns or use verified idempotency. Account for every input ID rather than hiding mixed results in one batch status.

Bad example

Restart all 120 after batch three, assume ten missing responses mean absence and create new records until success.

Good example

Persist 105 acknowledged, five failed and ten unknown with service/local identity mapping. Exclude acknowledged IDs on resume, handle explicit failures and reconcile unknown targets or use verified idempotent recovery. Retain checkpoints/open lists for all 120 without recreating the entire job. Fifty is this fixture's batch choice, not every service's limit.

Why the change matters

Checkpoints preserve confirmed work while per-item outcomes retain partial success. This prevents response loss from turning uncertain existing writes into duplicates.

Observable expectation

The teaching unresolved list contains 15 items, with ten reconciled before retry, while 105 IDs are not recreated. Counts reconcile to 120.

Inspect target identity/item evidence rather than counts only. No real leads are imported.

Limits

Checkpointing alone does not ensure exactly-once effects; receiver uniqueness/idempotency/reconciliation is needed. Read paging differs from write recovery, and local labels do not replace service IDs. Frozen batch guidance is not a universal current limit.