Files
pdoernerandGitHub 065c83f8ec Prioritize UI/tctl when system is throttled (#4623)
<!-- Describe what has changed in this PR -->
**What changed?**
* Added a new possible value for the `caller-type` header: `operator`
* This header should be set by web UI and tctl to indicate that requests
should be given higher precedence
* Rate limiters for persistence, history, matching, and visibility were
updated with a new priority corresponding to `operator` requests
* These new priorities have a lower RPS limit to prevent abusing the
header to get high priority for all requests. Currently the operator
priority is allowed 20% of the rate of the existing rate limiters

<!-- Tell your future self why have you made these changes -->
**Why?**
When the system is being throttled, users would like to be able to debug
using the web UI and/or tctl without running into rate limit errors

<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
New unit tests

<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
The operator RPS is set too low leading to new rate limit errors

<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No
2023-07-18 09:50:46 -07:00
..