Persist the next eligible attempt instead of sleeping in a worker

Classify the provider response

Determine whether the result is a rate limit, a transient failure, a permanent rejection or an unknown mutation outcome. Use the provider's documented status and headers.

Do not send every error through one exponential retry loop. Invalid input and revoked access usually need a different action from temporary capacity limits.

Record bounded diagnostic information without including tokens or full sensitive payloads.

Calculate and save eligibility

Use the supported provider timing hint and the application's bounded retry policy. Store the resulting next-attempt time with the operation rather than keeping a process asleep.

{
  "operationId": "sync-example-72",
  "providerScope": "account-example-a",
  "state": "waitingForBudget",
  "attempt": 3,
  "nextAttemptAt": "2026-09-11T02:15:00Z",
  "requestIdentity": "original-operation-request"
}

This illustrative timestamp is scheduling data, not a claim about a real provider response. The scheduler must use a consistent clock and validate any parsed external timing.

Release the worker claim according to the queue's concurrency model so another eligible operation can run.

Coordinate the shared scope

Update the relevant shared budget or pause state so other workers do not continue sending requests that are known to be premature.

Keep separate accounts independent where the provider's policy allows it. A limit on one customer connection should not automatically freeze every integration customer.

Use atomic admission for concurrent workers and define recovery if a worker crashes while holding a slot.

Treat a claimed concurrency slot as a lease with an explicit recovery mechanism if the scheduler design uses leases. A worker that dies must not occupy capacity forever, but expiry must also avoid admitting a second worker while the first continues producing effects. Use the queue or coordinator's supported ownership mechanism and keep mutation identity independent of the lease.

A restart test should therefore inspect both available capacity and duplicate effects. Restoring slots is useful only if it does not turn a stalled scheduler into two active executions of the same business command.

Test restart and expiration

Restart the scheduler while work is delayed and confirm that eligibility survives. Verify that no operation executes before the intended time.

Test missing headers, malformed timing and an elapsed retry budget. Work should reach a visible held or failed state rather than retry forever.

For mutations, retain the same business intent and applicable request identity. A later time slot does not by itself make repeating an uncertain external effect safe.