Retry once, validate the whole batch, then advance the checkpoint

The deterministic sample receives 429 with Retry-After: 2, records a simulated two-second delay, then receives 200 on attempt two. The maximum is three total attempts. A checkpoint advances only after the complete batch passes validation; HTTP 200 alone is not a commit decision.

Make the test finite and observable

This worked case is an offline response sequence, not a request to an external service. Set the maximum attempts to three, counting the initial attempt. The first fixture response has status 429 and a Retry-After header containing the integer 2. The second response has status 200 and a candidate payload. No third response is consumed when the successful candidate is complete and valid.

The lab reports a simulated wait of two seconds. It does not sleep for two seconds, measure a provider's recovery time or operate a retry queue. A deterministic simulation makes the transition trace inspectable: attempt number, status, delay decision and validation outcome can be compared with expected values without flaky timing tests or consuming anyone's request allowance.

Step	Sample result	Next action
Attempt 1	429; Retry-After: 2	Record simulated delay of 2 seconds
Attempt 2	200; candidate payload	Validate complete batch
Validation passes	All required records and pages accepted	Commit batch and checkpoint together
Validation fails	Invalid or incomplete candidate	Preserve previous checkpoint

Separate HTTP meaning from the sample policy

RFC 6585 defines 429 as a rate-limiting response and permits a Retry-After indication. RFC 9110 defines that header's delay-seconds and HTTP-date forms. This example uses only the unambiguous integer-seconds case. Three attempts is the publication's bounded demonstration policy, not a retry count required by either RFC and not a statement about a provider's service allowance.

A production client needs an explicit policy for absent or malformed headers, clock differences, unusually long delays, request timeouts and transient failures. It must also decide which requests are safe to repeat. Repeating a read is different from repeating a payment or write with side effects. The sample does not infer idempotency from an HTTP error code or promise that every request can be replayed.

Do not let transport success bypass data checks

Status 200 means a candidate response has arrived. Parse its envelope, verify required fields, reconcile all expected pages and inspect duplicate or conflicting record identities. If page one succeeds but page two is missing, the candidate remains incomplete. If a row has an invalid unit or an impossible date, accepting the transport response does not repair that record.

Keep the previous committed checkpoint until the complete candidate has passed. In an actual durable system, publish the new data and its checkpoint as one consistent change, or use an equivalent protocol that prevents a checkpoint from referring to absent data. The browser example explains this boundary without implementing a cloud database transaction or claiming protection against real process crashes.

Exercise exhaustion and replay separately

Replace the sequence with three unsuccessful attempts. The expected outcome is a terminal failure after attempt three, with no fourth request and no checkpoint advance. A finite retry budget prevents a broken integration from spinning indefinitely. Record the final status and reason, preserving the failure as failure rather than labeling the last known good batch as a newly completed refresh. Include the maximum-attempt setting in the trace so the result remains reproducible when that policy changes.

Next replay the same validated candidate. A production design should recognize its identity so it does not duplicate accepted records or send repeated downstream actions. That behavior requires storage and an idempotency design outside this static lab. Retain the response trace, validation decision and proposed checkpoint in a test report; these give an implementer concrete acceptance criteria while making clear which persistent guarantees still need to be built and verified.

Keep in the decision record

Three attempts means one initial request plus at most two retries.
A simulated delay tests policy without issuing a real request.
Commit only a fully validated batch, retaining the previous checkpoint on failure.

Source notes

Primary specifications support the interface descriptions. All downloadable response fixtures are synthetic. Access and rights checks are dated in the source inventory.

Version 1 · Published 16 October 2026. Inspect the method · Open the contract lab