Inbound data filters today run each condition independently with OR semantics: "Filter by error message" matches across all releases, and the "Releases" filter drops an entire release. There is no way to express "drop where exception.value matches <pattern> AND release < app@1.3.0" — the filters cannot be combined into a single scoped rule.
Current behavior
- Error message filter: matches pattern globally, no release scope
- Releases filter: drops all events for a release, regardless of error content
- No AND-composition between the two; separate rules are OR-ed together
Gap
Projects that backport fixes to older releases need to filter out known noisy errors only on affected versions without discarding newer traffic or unrelated errors from the same release. OR semantics make this impossible today.
Options
- Add a release condition (semver range, e.g.
< app@1.3.0) to the per-rule "Filter by error message" UI, evaluated as AND
- Introduce a general-purpose compound rule builder that AND-combines any available filter predicates
- Expose an advanced filter DSL for power users, leaving the simple UI unchanged
Action taken on behalf of Michael Chai.
Inbound data filters today run each condition independently with OR semantics: "Filter by error message" matches across all releases, and the "Releases" filter drops an entire release. There is no way to express "drop where
exception.valuematches<pattern>ANDrelease < app@1.3.0" — the filters cannot be combined into a single scoped rule.Current behavior
Gap
Projects that backport fixes to older releases need to filter out known noisy errors only on affected versions without discarding newer traffic or unrelated errors from the same release. OR semantics make this impossible today.
Options
< app@1.3.0) to the per-rule "Filter by error message" UI, evaluated as ANDAction taken on behalf of Michael Chai.