feat(billing): Define retention policy category identity#119775
Draft
dashed wants to merge 1 commit into
Draft
Conversation
Add an explicit, immutable mapping between billing policy categories, Sentry runtime categories, and retention wire aliases. Classify all other current proto categories as unsupported so future enum changes require deliberate retention review. Co-Authored-By: OpenAI GPT-5.6 <noreply@openai.com>
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.
Retention policy categories now have an explicit, immutable relationship to Sentry runtime categories, retention wire keys, and alias groups. This keeps billing protobuf identity distinct from runtime identity—for example, transactions and spans remain separate runtime categories while sharing the established
spanretention projection.Only the four mappings already used by current retention configuration are enabled: log bytes, transactions, spans, and trace metrics. Every other named billing protobuf category is explicitly classified as unsupported, and the exhaustive tests require a deliberate retention decision whenever that enum changes. The adapter is pure preparation for package policy work and does not change Relay configuration, customer serialization, quota routing, or other runtime behavior.
Focused coverage exercises all supported and unsupported decisions, unknown future values, strict and filtering lookup semantics, alias behavior, immutability, and parity with the existing retention wire mapping.