-
Notifications
You must be signed in to change notification settings - Fork 871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ContinueAsNewSuggested in scheduler workflow #4990
Conversation
suggestContinueAsNew = suggestContinueAsNew || iters <= 0 | ||
iters-- | ||
} else { | ||
suggestContinueAsNew = suggestContinueAsNew || info.GetContinueAsNewSuggested() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to use getVersion here since this may eagerly decide to continue as new
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This workflow uses a MutableSideEffect of tweakablePolicies to get the same effect as the versioning api, but in bulk. IterationsBeforeContinueAsNew has always been > 0, we'll change it to 0 to activate this code path (in a separate PR to allow this one to go in a patch release to enable downgrade)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I was missing that context. Thanks. LGTM.
**What changed?** Scheduler workflow uses server-sent suggestion for when to continue-as-new instead of fixed iteration count. Note this is not enabled in this PR yet. **Why?** Automatically handle history size/event count too large conditions (or any future conditions added by the server), which we might get if we do more work than expected per iteration. **How did you test it?** new unit tests, also replaced for loop with previous version to verify actual iteration count didn't change **Potential risks** The default history size suggestion is at 4MB, which we could hit after just a few large payload responses, and then we'd do continue-as-new more often than we might like.
**What changed?** Scheduler workflow uses server-sent suggestion for when to continue-as-new instead of fixed iteration count. Note this is not enabled in this PR yet. **Why?** Automatically handle history size/event count too large conditions (or any future conditions added by the server), which we might get if we do more work than expected per iteration. **How did you test it?** new unit tests, also replaced for loop with previous version to verify actual iteration count didn't change **Potential risks** The default history size suggestion is at 4MB, which we could hit after just a few large payload responses, and then we'd do continue-as-new more often than we might like.
What changed?
Scheduler workflow uses server-sent suggestion for when to continue-as-new instead of fixed iteration count.
Note this is not enabled in this PR yet.
Why?
Automatically handle history size/event count too large conditions (or any future conditions added by the server), which we might get if we do more work than expected per iteration.
How did you test it?
new unit tests, also replaced for loop with previous version to verify actual iteration count didn't change
Potential risks
The default history size suggestion is at 4MB, which we could hit after just a few large payload responses, and then we'd do continue-as-new more often than we might like.