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
The aws-sdk-go-v2 release on 2025-01-14 will contain a behaviorally-sensitive bugfix to waiters. This change, which is made in effort to align our SDK's waiter behavior with the standard imposed by the Smithy IDL, and fixes an issue where waiters were not correctly failing on un-matched errors, originally reported in #2937. Waiters will now fail on un-matched errors instead of spinning indefinitely (up to the maximum configured wait time).
This change may have breaking implications in certain scenarios. In any scenario where a waiter is called, some transient non-matching errors come back, and then the waiter eventually succeeds would now result in the waiter failing with an error. The waiter would now fail out immediately on the unmatched error, as the waiter specification says it should, instead of ignoring it and continuing to retry.
Removing these unnecessary calls reduces costs and makes error handling more robust by handling each error deliberately.
How can I tell if I'm impacted?
If you are making waiter calls that start failing after you update to this release, it is possible that you are impacted.
An example of a scenario with a transient error:
The caller provisions scoped credentials
The caller invokes a waiter with the scoped credentials
For some transient period, the credentials have not yet propagated across the service. Calls made using the waiter return a 403 or some other form of unauthorized exception
The credentials eventually propagate and the waiter continues to poll. The waiter ultimately succeeds.
You can inspect errors encountered during waiter operations through various means, such as
Setting ClientLogMode on service client Options to a value that includes aws.LogResponse
Inspecting the exception.type, exception.message, or api.error_code properties on root operation spans
It is up to the caller to determine whether a specific error is "transient" in the context of their application environment.
How can I reinstate the old behavior?
All waiters, in their options structure, e.g. s3.ObjectExistsWaiterOptions, support a Retryable field. This field is a function that accepts the request input, output, and operation error, and determines whether the result is retryable in the context of the waiter. You can wrap the default value for this field in order to retry additional, non-matched errors.
The following example accomplishes this with the s3.ObjectExistsWaiter
w:=s3.NewObjectExistsWaiter(svc, func(o*s3.ObjectExistsWaiterOptions) {
defaultRetryable:=o.Retryableo.Retryable=func(ctx context.Context, in*s3.HeadObjectInput, out*s3.HeadObjectOutput, errerror) (bool, error) {
if (/* check for the known transient error */) {
returntrue, nil
}
returndefaultRetryable(ctx, in, out, err)
}
})
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
-
The aws-sdk-go-v2 release on 2025-01-14 will contain a behaviorally-sensitive bugfix to waiters. This change, which is made in effort to align our SDK's waiter behavior with the standard imposed by the Smithy IDL, and fixes an issue where waiters were not correctly failing on un-matched errors, originally reported in #2937. Waiters will now fail on un-matched errors instead of spinning indefinitely (up to the maximum configured wait time).
This change may have breaking implications in certain scenarios. In any scenario where a waiter is called, some transient non-matching errors come back, and then the waiter eventually succeeds would now result in the waiter failing with an error. The waiter would now fail out immediately on the unmatched error, as the waiter specification says it should, instead of ignoring it and continuing to retry.
Removing these unnecessary calls reduces costs and makes error handling more robust by handling each error deliberately.
How can I tell if I'm impacted?
If you are making waiter calls that start failing after you update to this release, it is possible that you are impacted.
An example of a scenario with a transient error:
You can inspect errors encountered during waiter operations through various means, such as
ClientLogMode
on service clientOptions
to a value that includesaws.LogResponse
exception.type
,exception.message
, orapi.error_code
properties on root operation spansIt is up to the caller to determine whether a specific error is "transient" in the context of their application environment.
How can I reinstate the old behavior?
All waiters, in their options structure, e.g.
s3.ObjectExistsWaiterOptions
, support aRetryable
field. This field is a function that accepts the request input, output, and operation error, and determines whether the result is retryable in the context of the waiter. You can wrap the default value for this field in order to retry additional, non-matched errors.The following example accomplishes this with the
s3.ObjectExistsWaiter
Beta Was this translation helpful? Give feedback.
All reactions