Conversation
|
I see you updated files related to
|
|
✅ No conflicts with other open PRs targeting |
There was a problem hiding this comment.
@bolekk Do we still want to have limiters in place for Engine.Init? Or should we trust the limits from upstream, and just run whatever we are told at that point?
There was a problem hiding this comment.
I'd rather keep it for now (with a high setting). Hopefully once we get a proper queue they will be useful again.
2e56209 to
36b6ed3
Compare
36b6ed3 to
b9e1ec6
Compare
|
There was a problem hiding this comment.
I'd rather keep it for now (with a high setting). Hopefully once we get a proper queue they will be useful again.
| cfg.PerOwnerOverrides = normalizeOverrides(cfg.PerOwnerOverrides) | ||
|
|
||
| ownerLimit := cresettings.Default.PerOwner.WorkflowExecutionConcurrencyLimit // make a copy | ||
| ownerLimit := cresettings.Default.PerOwner.WorkflowLimit // make a copy |
There was a problem hiding this comment.
Is this already set to a high value in prod? We don't want to push a binary update before that is done.
There was a problem hiding this comment.
This one is not set since it was scheduled to be deprecated, and the default is now 1000.
…ncurrency]Limits (#21779)




https://smartcontract-it.atlassian.net/browse/CRE-2637
The PR proposes stacking all the
WorkflowExecutionConcurrencylimiters to be enforced where we expect (including an additionalPerOrg), and restore the regularWorkflowLimits (although we could just drop them).Requires: