feat(ingest): match messages in custom inbound filter#116701
Merged
Conversation
The custom-error generic filter only inspected `event.exception.values`, so events captured via `capture_message` (which carry no exception interface) were never filtered. Extend `_error_message_condition` with an opt-in `match_logentry` flag that also globs type-less patterns against `event.logentry.formatted`, and enable it for `_custom_error_filter`. A logentry message has no exception type, so only type-less patterns `(None, message)` apply to messages; patterns carrying a type stay exception-only. The built-in chunk-load and hydration filters keep `match_logentry=False`, so their generated config is unchanged.
loewenheim
approved these changes
Jun 2, 2026
jjbayer
reviewed
Jun 2, 2026
Comment on lines
+338
to
+340
| message_conditions.append( | ||
| {"op": "glob", "name": "event.logentry.formatted", "value": [value]} | ||
| ) |
Member
There was a problem hiding this comment.
We might also want to check event.logentry.message to match how relay implements legacy error messages: https://github.com/getsentry/relay/blob/f1b7447625d4e9f692c972c36bd6690e32c6ddce/relay-filter/src/error_messages.rs#L15-L23
3 tasks
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.
Extend the custom-error generic inbound filter to also match
capture_messageevents, not just exceptions.The condition built by
_error_message_conditiononly ever inspectedevent.exception.values, globbing each exception's type and message. Message events (capture_message) carry no exception interface — their text lands atevent.logentry.formattedafter normalization — so they slipped past the filter entirely.This adds an opt-in
match_logentryflag to_error_message_condition. When set, type-less patterns(None, message)additionally globevent.logentry.formatted, and the result is wrapped in a top-levelorof the exception branch and the message branches._custom_error_filterenables it; the built-inchunk-load-errorandreact-hydration-errorsfilters keep the default (match_logentry=False), so their generated Relay config is byte-for-byte unchanged.A logentry message has no exception type, so only type-less patterns can match a message — patterns that carry a type stay exception-only. When no type-less pattern is configured, the condition collapses back to the original exception-only shape (no empty
orwrapper).Note: tests assert the generated
RuleConditionstructure and simulate glob matching locally; they do not exercise real Relay evaluation ofevent.logentry.formatted. That field is the canonical normalized message path used elsewhere in Sentry (grouping, json pruning), so the name is correct, but full end-to-end confirmation would require sending a message event through Relay with the filter configured.