Use linear backoff on the SDK v3 Waiter due to failure rate for short… #29
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… running tasks
What it solves
Since v3 the AWS SDK uses a Waiter with exponential back-off and jitter to check for the state of the task. This is in general a good thing, as it reduces the load on the AWS API and is more efficient.
HOWEVER:
If the task that is started is short-lived, the Waiter might not be able to catch the task in the "RUNNING" state at all, because the potential back-off method will increase the delay to a value that is too high.
The Waiter will randomly catch it in the "STOPPED" state and throw an error as the exit code is not checked in the waiter. To combat this we use the old behavior, we will go back to use the linear back-off by setting both delay values to the same value.
See: https://aws.amazon.com/blogs/developer/waiters-in-modular-aws-sdk-for-javascript/
Readiness Checklist
Author/Contributor
Reviewing Maintainer
breaking
if this is a large fundamental changeautomation
,bug
,documentation
, orenhancement
bump:patch
,bump:minor
, orbump:major
if this PR should create a new release