Verify a Sentry suppression filter is alive by checking for the tag it sets, not by reading it

A beforeSend filter that drops known-benign errors is write-once code that nobody revisits, and it can be dead on arrival without any symptom other than the noise it was supposed to remove.

Concrete case: a SvelteKit app suppressed version-skew chunk-load errors on their first occurrence (because handleError auto-reloads the page) and only reported them if a reload had already been attempted:

const mechanismType = event?.exception?.values?.[0]?.mechanism?.type;
if (mechanismType === 'sveltekit' && is_stale_chunk_message(message)) {
    // drop first occurrence, else tag chunk_reload_failed
}

@sentry/sveltekit 10.x never emits a bare sveltekit. Sampling 100 prod events of the issue gave:

auto.function.sveltekit.handle_error                    88
auto.browser.global_handlers.onunhandledrejection       11
auto.function.sveltekit.load                             1

So the branch had never executed -- not an SDK-upgrade regression either: the dependency had not been bumped since the integration was added, so it was wrong from the day it was written (14 months of noise).

The generalizable technique. The filter both suppressed AND set a tag (chunk_reload_failed) on the non-suppressed path. That tag is a liveness probe you get for free: sample the events the filter claims to handle and check whether the tag appears.

GET /api/0/organizations/{org}/issues/{id}/events/?environment=prod&limit=100
# then Counter over each event's tags

chunk_reload_failed was absent from all 100 events, which is proof the branch never ran -- independent of, and stronger than, reading the code. Two practical corollaries:

• Design filters to be observable. If a filter only suppresses, it is unfalsifiable. Have it set a tag on the path it lets through, so you can audit it later.
• Prefer a substring test over equality on any SDK-provided string. mechanismType.includes('sveltekit') survives the SDK renaming its mechanisms; === 'sveltekit' does not. Equality on a vendor-controlled enum is a silent-failure shape.

One judgement call worth copying: do NOT widen the fix to suppress every matching error. Errors arriving as onunhandledrejection bypass the framework error hook entirely, so no auto-reload is coming for them -- suppressing those would hide a genuinely broken page rather than a stale tab. Scope the suppression to exactly the paths where the compensating action actually runs.

Also from the same event sample, worth doing routinely: 28% of the events were crawlers by the browser tag (GoogleOther, Googlebot, Baiduspider-render, bingbot), and the per-day histogram showed one spike aligned to a deploy and one with no deploy behind it. latest-event alone would have implied a user-facing regression. Note the issue-events LIST endpoint omits entries[].mechanism; read mechanism from the event's tags instead.