| Previous | Next |
| ERROR_CONNECTION_ABORTED | ERROR_CONNECTION_COUNT_LIMIT |
ERROR_RETRY
The operation should be retried.
ERROR_RETRY has value 1237 (0x4D5). Unlike a generic failure, this result explicitly suggests another attempt. It still does not authorize an unbounded loop or guarantee that repeating a non-idempotent operation is safe.
Preserve the operation context
Record the API, resource identity, attempt number, elapsed time, and any preceding transient condition. Some subsystems return 1237 after internal state changes, contention, or recovery work. Without context, support teams cannot tell whether the retry was expected or masking a persistent defect.
Designing the retry loop
- set a maximum attempt count or absolute deadline
- use exponential or otherwise bounded backoff with jitter
- refresh handles, metadata, or authoritative state when appropriate
- stop immediately on a different deterministic error
- honor application shutdown and user cancellation
- emit one summarized event rather than one alert per attempt
Idempotency and duplicate effects
Before retrying a write, determine whether the first attempt could have committed. Use transaction IDs, conditional updates, durable operation keys, or a query for current state. Replaying a create, charge, rename, or message send without deduplication can turn a recoverable status into data corruption or duplicate work.
When not to retry
Do not keep retrying after the deadline, after the target is deleted, during explicit cancellation, or when repeated 1237 results show no state transition. Escalate with the accumulated attempt history. A service that retries forever can prevent failover and hide a resource that is permanently stuck.
Difference from busy and timeout results
ERROR_BUSY states that a resource is occupied but does not always prescribe a retry strategy. ERROR_TIMEOUT says an interval expired and leaves ambiguity about completion. Error 1237 directly requests a retry, while the caller remains responsible for timing and safety.
Operational telemetry
- percentage of operations that need at least one retry
- distribution of successful attempt numbers
- total added latency and exhausted retry budgets
- resource or host concentration of 1237 results
- correlation with failover, storage, or network events
Example
A storage-management call returns 1237 during a brief ownership transition. The service waits with jitter, refreshes the resource handle, and retries using the same idempotency key. The second attempt succeeds; telemetry records one recovered transient instead of raising two independent incidents.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: Retry pattern
- Microsoft: Transient fault handling
Looking for a different code? Search another status or error code.