-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Cappl 588/rate limit per workflow #16672
base: develop
Are you sure you want to change the base?
Conversation
AER Report: CI Coreaer_workflow , commit , Clean Go Tidy & Generate , Detect Changes , Scheduled Run Frequency , Core Tests (go_core_tests) , Core Tests (go_core_tests_integration) , Core Tests (go_core_fuzz) , Core Tests (go_core_race_tests) , Core Tests (go_core_ccip_deployment_tests) , GolangCI Lint (.) , test-scripts , lint , SonarQube Scan 1. GolangCI Lint errors:[lint]Source of Error:
Why: The errors are caused by violations of Go naming conventions and improper usage of Go syntax. Specifically, the use of underscores in variable names, improper variable naming, and incorrect usage of the Suggested fix: Rename the variables to follow Go naming conventions (e.g., AER Report: Operator UI CI ran successfully ✅ |
ad6dcae
to
059bb26
Compare
Flakeguard SummaryRan new or updated tests between View Flaky Detector Details | Compare Changes Found Flaky Tests ❌1 Results
ArtifactsFor detailed logs of the failed tests, please refer to the artifact failed-test-results-with-logs.json. |
ce9c1de
to
9925ad8
Compare
@@ -836,7 +836,7 @@ func (e *Engine) workerForStepRequest(ctx context.Context, msg stepRequest) { | |||
|
|||
var stepStatus string | |||
switch { | |||
case errors.Is(capabilities.ErrStopExecution, err): |
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.
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.
Can you say more about why this change was necessary?
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.
Tagging @MStreet3 , because he made the original change, I just fixed it to work from what he had.
I'm guessing that he noticed that the usage was wrong, which flipped it from
// Not intended usage, see errors.Is doc
case errors.Is(capabilities.ErrStopExecution, err):
// Intended usage
case errors.Is(err, capabilities.ErrStopExecution):
Moving it to case errors.Is(err, capabilities.ErrStopExecution):
caused tests to fail, so I changed it to what it is now.
if !c.rateLimiter.Allow(body.Sender) { | ||
// error is logged here instead of warning because if a message from gateway is rate-limited, | ||
// the workflow will eventually fail with timeout as there are no retries in place yet | ||
c.lggr.Errorw("request rate-limited") | ||
l.Errorw("request rate-limited") | ||
return |
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.
Technically out of scope, but could we return an error here back to the caller? I think this results in nicer UX by telling users they were rate limited rather than returning a timeout.
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.
Agreed. Changing.
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.
…GatewayMessage on rate limit
|
@@ -36,7 +37,13 @@ const ( | |||
|
|||
var defaultConfig = Config{ | |||
ServiceConfig: webapi.ServiceConfig{ | |||
RateLimiter: common.RateLimiterConfig{ |
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 is a breaking API change I think 🤔 ?
PerWorkflowRPS: 100.0, | ||
PerWorkflowBurst: 100, | ||
}, | ||
IncomingRateLimiter: gwcommon.RateLimiterConfig{ |
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.
IMO not worth having an extra struct + a duplicated implementation -- can we somehow either reuse gwcommon.RateLimiterConfig but with a different struct and constructor for config?
eg.
type OutgoingRateLimiter struct {
...
PerWorkflowRPS
PerWorkflowBurst
}
func NewOutgoingRateLimiter(rl ...) gwcommon.RateLimiter {
return gwcommon.RateLimiter{
... convert between the two types
}
}
Requires
Supports