Turn a refusal into a next action
Your objectiveChoose a safe next action after a rate-limit response.
Understand the idea.
A retry is a new operation, not the continuation of an old one. The collector needs to decide whether repetition is safe and when it is allowed. HTTP Retry-After can name a delay in seconds or an HTTP date. Keep the supplied waiting period distinct from your application’s own fallback policy. A timeout without that header needs a local decision, not an invented instruction from the publisher.
A worked example.
At 10:00 a source returns a 120-second waiting period. At 10:01 another source on the same constrained host becomes due. A host-aware policy can defer the second request until the shared waiting period ends. That is a deliberate wait, not evidence that the worker is stuck.
Try the reasoning.
Draw a four-row timeline: first attempt, refusal, attempted manual refresh and earliest permitted retry. Label the source of every deadline. Do not send requests to a real publisher.
Carry it into practice.
In an integration status view, show both the last outcome and next eligible attempt.
Read the reference: IETF · HTTP semantics ↗