Retry-After Through a Proxy: Test Seconds, HTTP Dates and the Actual Dispatch Boundary

A proxy worker can have exponential backoff and still retry too early: it reads a seconds value as milliseconds, parses an HTTP date in the machine's local timezone, or caps a long server delay at a shorter local maximum. This guide tests the Retry-After parser and the handoff to scheduling for authorized read-only jobs. The examples are synthetic acceptance cases, not measured behavior of 98IP or a target.

1. Separate a server waiting instruction from retry permission

Retry-After can carry a non-negative integer delay in seconds or an HTTP date. It is used with service-unavailable responses, rate limits and some redirects. This article concentrates on an owned 503 test fixture. Decide separately whether that request is eligible for another attempt, how much time and attempt budget remain, and which route or account the pause applies to.

A header does not prove an interrupted write was uncommitted. Do not apply this read-only fixture to purchases or other state changes without their own duplicate-protection contract. For the wider retry ownership, jitter and load-budget design, use the existing proxy retry storm guide. Here the acceptance question is narrower: does the next actual dispatch respect the computed not-before boundary?

2. Define the parser outputs before connecting a worker

Preserve a bounded sanitized raw value, receipt time and parse result: valid seconds, valid HTTP date, absent, invalid or out of supported range. Do not collapse every failure into zero. Use an HTTP-date parser rather than a locale-sensitive general date guess. Do not split the field on commas: an HTTP date itself includes a comma. Multiple ambiguous field values need an explicit invalid-input policy.

For a seconds value, start the delay from receipt and make the units explicit at the scheduler boundary. Parse into a checked numeric representation and reject overflow before multiplying into milliseconds or nanoseconds. Zero is valid input but is not an instruction to spin without budgets. Empty, negative, fractional and arbitrary word values need a deliberate fallback or stop decision, not accidental immediate dispatch.

3. Test the time model with a controllable clock

1. Use a local or owned staging fixture that returns a controlled 503 followed by a read-only success. Give the response and every later dispatch independent correlation IDs.
2. Inject a controllable clock into parser and scheduler tests. Record wall-clock receipt time and a monotonic receipt tick; do not wait for hours in real time.
3. For a valid delay of 2 seconds, assert no network dispatch just before the boundary, then advance to the boundary and allow at most one eligible attempt. A queued callback firing early is not sufficient evidence; observe the actual outbound dispatch.
4. Use a valid GMT HTTP date two seconds after the controlled wall-clock receipt time. Repeat under different machine timezones and require the same instant.
5. Move the wall clock forwards and backwards after the delay is accepted. A local duration should continue against a monotonic deadline within the process, rather than expiring early when the wall clock jumps.

For an absolute date, calculate against a trustworthy wall-clock basis at receipt, then schedule the remaining duration. If clock synchronization is uncertain, mark the date decision uncertain and pause or apply a documented conservative policy. Do not silently substitute the response Date header as an exact clock: transit delay and cached responses complicate that assumption. A past date adds no future waiting requirement, but ordinary retry and concurrency budgets still apply.

4. Exercise malformed values and deadline conflicts

• Absent field: use the documented ordinary retry policy, not an invented server delay.
• Empty text, -1, 0.5 or a nonsensical date: record invalid input and take the chosen safe fallback or stop path.
• A huge integer outside supported arithmetic or timer range: no wraparound, negative duration or immediate timer. Defer to a scheduler that can represent the boundary, or stop for review.
• A valid delay beyond the job deadline: do not shorten it to fit. Mark this attempt deferred or deadline-exceeded without a request before the server boundary.
• A valid delay beyond the in-process timer maximum: keep the full not-before value in durable scheduling or stop. A local timer cap is not permission to retry earlier.

These are acceptance policies for your system, not a claim that HTTP defines one universal malformed-header recovery algorithm. Record which cases are supported, which are rejected and which require intervention. If a later local backoff or bounded non-negative jitter applies too, dispatch no earlier than both the server boundary and that local policy permit.

5. Verify queue and restart behavior

Persist operation ID, attempt number, scope, parse decision, earliest eligible UTC instant, original receipt information and job deadline in non-secret task metadata. Monotonic ticks belong to their process and cannot be reused after a restart. On restart, reconstruct against a trustworthy clock, recheck the deadline and acquire a single task lease before dispatch.

Stop the test worker halfway through the waiting interval and restart it with the same operation. Assert no duplicate job, no reset to immediate execution and no lost server boundary. Test cancellation while waiting and a late timer callback after cancellation. Both must leave the job inactive. Test two workers competing at the due time and verify one dispatch under your queue's lease contract.

A per-job delay does not automatically coordinate every worker sharing a target or account. Apply the agreed pause scope and test an affected companion job plus an unrelated healthy job. Do not evade a server pause by rotating exits or credentials. A due time merely permits reconsideration; it does not override a later shutdown, cancellation or access refusal.

6. Compare the owned fixture through 98IP

After local tests pass, run a small real-time case through the approved baseline and your selected residential proxy route. The 98IP dynamic residential IP page is relevant when these workers need selected regional exits; obtain supported settings from the configuration documentation and the account. Keep region and session policy fixed and verify the observed egress.

Compare what the owned receiver sent, what the client parsed and when the next request actually arrived. A returned header is not proof that an SDK honors it. No client compatibility, timing precision, throughput or failed-request billing result is promised here. Use short synthetic delays, bounded traffic and authorized data, and inspect actual usage.

7. Release evidence and FAQ

• Seconds and HTTP dates produce explicit units and the intended not-before boundary across timezones.
• Invalid values, overflow, missing headers and clock uncertainty follow documented paths.
• Job deadlines and timer caps never shorten a valid server pause.
• Restart, cancellation, competing workers and scoped companion jobs have receiver-observed outcomes.
• Logs retain operation IDs and timing decisions without proxy passwords, authorization headers, cookies or customer data.

Can I sleep for my configured maximum instead? If that maximum is earlier than a valid server boundary, no. Defer durably or terminate this attempt rather than sending early.

Does a past date mean retry immediately forever? No. It contributes no positive future wait; retry eligibility, ordinary backoff, attempt limits and cancellation still control the job.

Should I calculate each wait again from receipt? Preserve the original boundary. Repeatedly adding the entire seconds value after each queue wakeup can postpone a task indefinitely, while discarding it after restart can dispatch too early.