Skip to content

feat(inbound-filters): Generate Relay rules from custom inbound filters#119816

Draft
shellmayr wants to merge 3 commits into
masterfrom
feat/custom-inbound-filters-relay-config
Draft

feat(inbound-filters): Generate Relay rules from custom inbound filters#119816
shellmayr wants to merge 3 commits into
masterfrom
feat/custom-inbound-filters-relay-config

Conversation

@shellmayr

Copy link
Copy Markdown
Member
  • Translate active CustomInboundFilter rows into Relay generic inbound filters during project config generation, gated behind organizations:inbound-filters-v2 (nested inside the existing projects:custom-inbound-filters check, matching the API endpoints)
  • Conditions within a filter are combined with AND; glob values within a single condition are ORed
  • release conditions glob against the release field of the filter's data category: event.release for error and release-only filters (mirroring the legacy releases filter), log.attributes.sentry.release.value for log filters, trace_metric.attributes.sentry.release.value for trace metric filters
  • error_message conditions match exception type, exception value, and logentry.formatted — the legacy "{type}: {value}" concatenation is not expressible in Relay's rule DSL
  • A filter with any untranslatable condition is skipped entirely, since dropping only the broken condition would filter more data than configured
  • Move CustomInboundFilterConditionType into the model module so ingest code doesn't import from the API layer
  • Schedule Relay project config invalidation when filters are created or deleted, or when active/conditions change
  • Tests validate the generated conditions (including combined error message AND release) against Relay's actual rule parser via sentry_relay.processing.validate_rule_condition

Closes TET-2703

Translate active CustomInboundFilter rows into Relay generic inbound filters in the project config, gated behind organizations:inbound-filters-v2. Conditions within a filter are combined with AND; release conditions target the release field of the filter's data category (events, logs, or trace metrics). Filter mutations now schedule a project config invalidation so changes propagate without waiting for the cache TTL.
@linear-code

linear-code Bot commented Jul 16, 2026

Copy link
Copy Markdown

TET-2703

@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Jul 16, 2026
One test case per filter shape via pytest.param instead of a separate test function each.
Replace the release-only field constant and per-type branching with a target item type enum and a per-target map of condition type to field path (or condition builder), so new condition types and targets are table entries instead of new code paths.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant