feat(queue): provide a way for pipeline stages to specify a backoff period #4841
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
xibz
reviewed
Feb 17, 2025
| @@ -316,6 +316,9 @@ class RunTaskHandler( | |||
| * `tasks.aws.backOffPeriod = 80000` | |||
| * `tasks.aws.someAccount.backoffPeriod = 60000` | |||
| * `tasks.aws.backoffPeriod` will be used (given the criteria matches and unless the default dynamicBackOffPeriod is greater). | |||
| * | |||
| * This function also considers the `backoffPeriodMs` property in a stage | |||
| * configuration. If it's larger than the above, it's used. | |||
There was a problem hiding this comment.
Im not following this comment. Where is the logic to determine what is used by magnitude?
There was a problem hiding this comment.
Nvm. I see it in the code below that needed expanding in gh
xibz
approved these changes
Feb 17, 2025
…eriod via a new backoffPeriodMs stage configuration property. Before this, pipeline authors had no control over the backoff period. It came from either spinnaker configuration properties or implementations of RetryableTask.getDynamicBackoffPeriod. This makes it possible for pipeline authors to, for example, control the delay between attempts when webhook stages retry. The actual backoff used is the largest of: - backoffPeriodMs in the stage - tasks.global.backOffPeriod - tasks.<cloud provider>.backOffPeriod - tasks.<cloud provider>.<account name>.backOffPeriod
since getTimeout and getBackoffPeriod were basically the same.
since Integer, Long and Double all extend from Number. Also, Optional.map isn't necessary since instanceof returns false when value is null.
to mention backoffPeriodMs stage property
dbyron-sf
force-pushed
the
configurable-backoff
branch
from
af3d288 to
7d00b21
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
via a new backoffPeriodMs stage configuration property. Before this, pipeline authors had no control over the backoff period. It came from either spinnaker configuration properties or implementations of RetryableTask.getDynamicBackoffPeriod.
This makes it possible for pipeline authors to, for example, control the delay between attempts when webhook stages retry. The actual backoff used is the largest of:
backoffPeriodMsin the stagetasks.global.backOffPeriodtasks.<cloud provider>.backOffPeriodtasks.<cloud provider>.<account name>.backOffPeriod