fix: match rate limits by data category not envelope item type#5412
Merged
Conversation
Rate limits in the `X-Sentry-Rate-Limits` header are keyed by data category (e.g. `error`, `monitor`, `log_item`, `metric_bucket`), which is not always the same as the envelope item type (`event`, `check_in`, `log`, `statsd`). `RateLimitCategory.Matches` compared the category name against the raw item type, so limits for errors, check-ins and logs were silently ignored — the SDK kept sending that data instead of backing off, and client reports mis-attributed the resulting drops to `default`. - Map every emitted item type to its correct data category, and add the missing `monitor`/`log_item`/`trace_metric`/`metric_bucket` constants - Match rate limits against the item's data category - Record dropped logs/metrics under their real category in client reports - Never rate-limit client reports (they are the `internal` category) Closes #4535 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jamescrosswell
commented
Jul 20, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5412 +/- ##
==========================================
+ Coverage 74.59% 74.62% +0.03%
==========================================
Files 512 512
Lines 18666 18672 +6
Branches 3659 3657 -2
==========================================
+ Hits 13923 13934 +11
+ Misses 3868 3865 -3
+ Partials 875 873 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The 10.0.302 workload ships the iOS SDK pack 26.5.10301, which requires Xcode 26.6. CI was pinning Xcode 26.5, causing iOS/MacCatalyst builds and device tests to fail. The macos-26 runner already used by these jobs has Xcode 26.6 available, so switch the pin to it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dependabot bumped only codeql-action/init to 4.37.1, leaving analyze on 4.37.0. CodeQL requires all steps use the same version, so analyze failed with "Loaded a configuration file for version '4.37.1', but running version '4.37.0'". Pin analyze to the same v4.37.1 SHA. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jamescrosswell
commented
Jul 21, 2026
…x/rate-limit-data-categories
- Collapse RateLimitCategory.Matches to an expression body (IsMatchAll || ...) - Trim the data-category comment to a single line - Clarify the client_report -> internal mapping comment: client reports are never rate-limited by Relay, rather than implying an "internal" limit exists Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jamescrosswell
commented
Jul 22, 2026
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 85cefb0. Configure here.
Without this mapping, feedback items fell through to "default" and no longer matched the "feedback" rate-limit category once matching switched from item type to data category - a regression flagged by review bots. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…into fix/rate-limit-data-categories
Litarnus
approved these changes
Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Rate limits in the
X-Sentry-Rate-Limitsheader are keyed by data category (error,monitor,log_item,metric_bucket, …) in Relay/Rust.However since 2020 our SDK matched them against the envelope item type (
event,check_in,statsd,log…). Those two only line up by coincidence for some types, so limits silently didn't match for the rest — the SDK ignored the backoff and kept sending.errorwas broken from day one: Relay has always senterror, we compared it to the item typeevent. (Not a Relay change — we were wrong from our first rate-limit commit.)monitor(check-ins) andlog_item(logs) broke the moment we added those features: the category already existed in Relay, we just never mapped the item type to it.metric_bucketwas patched in 2024 with a one-off special case rather than a real fix.Additionally, since we'd keyed client reports the default category, if Default ever got rate limited, client reports would erroneously be dropped.
Ultimately we had two parallel notions of an item's category — a correct
EnvelopeItem.DataCategorymap (used for client-report accounting) and a separate raw-item-type string comparison in the rate-limiter. They were never reconciled, so every new item type whose type-string ≠ category-name reintroduced the bug.Fix
The fix deletes the item-type comparison and matches on
item.DataCategory. Any new item type now only needs itsDataCategorymapping (which it needs anyway for client reports), and rate limiting follows automatically, so this class of bug can't silently reappear.Changelog Entry
The SDK was incorrectly ignoring server rate limits for errors, check-ins, and logs
Issues
Closes #4535