GUIDES · BETSLIP DOCTOR
Why does BSD sometimes ask me to wait before retrying a failed request?
A service response can ask the client to wait before another request, and the client can apply a bounded retry policy for that particular caller. Some longer delays lead to a recoverable error instead of leaving a spinner running. The retry rules are not universal, and waiting does not guarantee the next request will succeed.
For BSD readers deciding what to do after a request fails or remains pending · Updated
A wait can reflect service backoff
For some temporary service responses, BSD's transport reads retry guidance from the response and keeps a cooldown for the affected client. That gives the service time before another attempt. It is different from a permanent access refusal, and the wait does not promise that the underlying request will later succeed.
The recorded client policy treats status and retry guidance as inputs. It does not set one public retry timetable for every screen or request.
Automatic retries depend on the request
The shared retry policy is bounded and avoids retrying an aborted request or certain client errors. A caller can also choose not to retry automatically. If the client shows a recoverable error, use the recovery choice it currently offers and follow any displayed wait.
Repeated taps do not bypass a service cooldown, an access refusal, or a subscription requirement. If the same error remains after the wait, use the current support path rather than assuming the request completed.
Hypothetical: a request receives a retry delay
Imagine a reader submits a request and the service responds with retry guidance. The current client waits or shows its recoverable error state according to that request's policy. Tapping repeatedly does not remove the service delay, and the example does not promise that a later attempt will succeed.
Related questions
Does every BSD request use the same retry delay?
No. The retry policy is bounded, but behavior depends on the caller and response. The source does not establish one universal timetable.
Will trying again after a wait guarantee success?
No. A retry delay controls when an attempt may run; it is not proof that the service problem has cleared or that the request was completed.