-
Notifications
You must be signed in to change notification settings - Fork 805
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
Add metrics for external calls for the workflow ID specific rate limits. #5684
Add metrics for external calls for the workflow ID specific rate limits. #5684
Conversation
This generates a rate limiter around the external calls in the history hander, generated using this command: .build/bin/gowrap gen -p ./service/history -i Handler -t ./service/history/templates/ratelimited.tmpl -o ./service/history/wrappers/ratelimited/handler_generated.go -v handler=History
When service and handler are in the same package we cannot introduce wrappers around handler in another package as that will create a circular dependency: history (service) -> wrapper -> history (handler) This moves handler to the handler package. Also moves the engine implementation to it's own package as there was a circular dependency history (service) -> handler -> history (engine) The engine implementation cannot be in the same package as the engine interface, as there is a dependency engineimpl -> shard -> engine (Interface) Moved all the error values in handler to a constants package as at least one of them (ErrRunIDNotValid) is referenced from two different packages (handler and engine tests)
…ternalCallsMetrics
Pull Request Test Coverage Report for Build 018deeed-f764-410d-be86-f1b4e7b1312fDetails
💛 - Coveralls |
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.
I would consider using a dynaimc-config switch in the rate-limit to rollout rather than just emitting metrics and then adding a second follow-up PR here, as having two PRs might be fairly slow to rollout, but no concerns
+1 on David's point. Might be better to introduce a dry run mode and control it with dynamic config. |
"ratelimitTypeUserPerID" | ||
}} | ||
|
||
{{ $workflowID := ( get ( get $ratelimitTypeMap $method.Name ) "workflowID" ) }} |
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.
nit: call the fields with Field suffix:
$workflowIDField
So it is easier to read the code.
What changed?
Added a wrapper around the history handler which logs rate limit metrics the external calls we want to rate limit with the workflow specific rate limiter.
Why?
We want to investigate the rate limiting for all external calls that can cause hot shards, before we deploy.
How did you test it?
Unit tests and local tests
Potential risks
Release notes
Documentation Changes