-
Notifications
You must be signed in to change notification settings - Fork 415
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
fix: API usage alerting in production #3507
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Uffizzi Preview |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3507 +/- ##
==========================================
- Coverage 95.86% 95.86% -0.01%
==========================================
Files 1099 1099
Lines 34282 34376 +94
==========================================
+ Hits 32864 32954 +90
- Misses 1418 1422 +4 ☔ View full report in Codecov by Sentry. |
Co-authored-by: Kim Gustyr <[email protected]>
…e-alerting-in-production
…gsmith/flagsmith into fix/api-usage-alerting-in-production
Thanks for submitting a PR! Please check the boxes below:
pre-commit
to check lintingdocs/
if required so people know about the feature!Changes
In order to address #3461 two main issues were handled. First, an incorrectly implemented InfluxDB query was fixed in order to get the full API usage counts in a single scalar. Second, a local evaluation mode Flagsmith client was introduced in order to allowlist organisations into alerting so that any given mistake in the API alerting code won't disrupt too many users.
How did you test this code?
The API usage code was tested against the staging InfluxDB setup with a date range window set to about a year to gather the most amount of data. Thousands of organisations were tested without the same failure once the fix was implemented.
The local evaluation Flagsmith client code was tested locally with settings variables set to appropriate values. During testing an issue with local evaluation cropped up where flags were not present if the method call happened before the local evaluation cache had been set, so this was temporarily worked around with a small sleep on the client's instantiation.