You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks the 2026 retry updates for AWS SDK for PHP 3.x. See the announcement blog post for the full story across all AWS SDKs, including how to tell if you are affected.
Status
Opt-in available in
aws-sdk-php version 3.380.0 and later
Opt-in flag
AWS_NEW_RETRIES_2026=true
Default rollout
No sooner than November 2026
What changed
When you set AWS_NEW_RETRIES_2026=true, the default retry mode changes from legacy to standard. Several other retry defaults also update. The standard mode adds a retry quota that limits retries when failures are widespread, so your application fails fast instead of waiting on retries that are unlikely to succeed. This also helps outages resolve faster.
If you have explicitly configured a retry mode, max attempts, or backoff, your value takes precedence for that setting.
Setting
Before
After
Default retry mode
legacy
standard
Transient (non-throttling) base delay
100 ms
50 ms
Throttling base delay
100 ms
1,000 ms
Max attempts
3
3 (unchanged)
Retry quota
None
500 tokens
Transient retry quota cost
5 tokens
14 tokens
DynamoDB and DynamoDB Streams
Transient (non-throttling) base delay
50 ms
25 ms
Throttling base delay
50 ms
1,000 ms
Max attempts
11
4
DynamoDB defaults use a shorter base delay to match its low-latency profile. The additional attempt keeps the last retry's maximum backoff comparable to the general default.
Transient errors (such as 500s and connection resets) now use a much shorter backoff than throttling errors (where the service asks you to slow down). For details on backoff timing, error classification, and the retry quota, see Retry behavior in the AWS SDKs. For retry mode selection and configuration options, see Retry behavior in the AWS SDKs.
How to opt in
Update to aws-sdk-php version 3.380.0 or later, then set the environment variable:
export AWS_NEW_RETRIES_2026=true
How to revert
During the opt-in period, remove the environment variable:
unset AWS_NEW_RETRIES_2026
After the default rollout (no sooner than November 2026), the new behavior becomes the default. To restore previous behavior, set the retry mode to legacy:
For most workloads, the change is invisible or strictly better. Transient errors recover faster because the base delay is significantly shorter.
Max attempts decreased. DynamoDB max attempts decreased from 11 to 4. If your workload relied on a higher retry count to eventually succeed, you may see more errors surfaced to your code. You can override max_attempts to restore your previous value.
This SDK now has a retry quota. Legacy mode had no standardized retry quota. The SDK would retry up to the max attempt count regardless of how many requests were failing. Standard mode tracks a token budget and returns errors directly when failures are widespread, so your application fails fast and frees up resources for requests that can succeed. For details, see retry quota.
Retry quota activates sooner for transient errors. Each transient retry costs 14 tokens (previously 5 for most errors). During sustained transient failures (such as 500s and connection resets), the retry quota triggers at a lower failure rate than the previous version of standard mode. Throttling retries cost 5 tokens.
Long-polling operations now back off when the retry quota is depleted. Operations like SQS.ReceiveMessage apply a backoff delay before returning an error, even when retries are blocked. Without this, polling loops tighten during outages, spiking client CPU usage and generating additional load that can delay recovery. For details, see long-polling operations.
Overriding specific settings
You do not have to accept all changes as a bundle. If you opt in but want to keep a specific previous value, set it explicitly. Precedence applies per setting.
For example, to use the new backoff timing but keep a higher DynamoDB max attempts:
If you encounter unexpected behavior or have questions, comment on this issue. Your feedback during the opt-in period directly shapes when and how we make this the default.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Status
aws-sdk-phpversion3.380.0and laterAWS_NEW_RETRIES_2026=trueWhat changed
When you set
AWS_NEW_RETRIES_2026=true, the default retry mode changes fromlegacytostandard. Several other retry defaults also update. Thestandardmode adds a retry quota that limits retries when failures are widespread, so your application fails fast instead of waiting on retries that are unlikely to succeed. This also helps outages resolve faster.If you have explicitly configured a retry mode, max attempts, or backoff, your value takes precedence for that setting.
legacystandardTransient errors (such as 500s and connection resets) now use a much shorter backoff than throttling errors (where the service asks you to slow down). For details on backoff timing, error classification, and the retry quota, see Retry behavior in the AWS SDKs. For retry mode selection and configuration options, see Retry behavior in the AWS SDKs.
How to opt in
Update to
aws-sdk-phpversion3.380.0or later, then set the environment variable:export AWS_NEW_RETRIES_2026=trueHow to revert
During the opt-in period, remove the environment variable:
unset AWS_NEW_RETRIES_2026After the default rollout (no sooner than November 2026), the new behavior becomes the default. To restore previous behavior, set the retry mode to
legacy:export AWS_RETRY_MODE=legacyOr in code:
Where you might notice a difference
For most workloads, the change is invisible or strictly better. Transient errors recover faster because the base delay is significantly shorter.
max_attemptsto restore your previous value.SQS.ReceiveMessageapply a backoff delay before returning an error, even when retries are blocked. Without this, polling loops tighten during outages, spiking client CPU usage and generating additional load that can delay recovery. For details, see long-polling operations.Overriding specific settings
You do not have to accept all changes as a bundle. If you opt in but want to keep a specific previous value, set it explicitly. Precedence applies per setting.
For example, to use the new backoff timing but keep a higher DynamoDB max attempts:
For the full list of configurable settings and their precedence, see Retry behavior in the AWS SDKs.
Feedback
If you encounter unexpected behavior or have questions, comment on this issue. Your feedback during the opt-in period directly shapes when and how we make this the default.
Beta Was this translation helpful? Give feedback.
All reactions