When using @sentry/sveltekit's handleErrorWithSentry wrapper with a custom SvelteKit client handleError callback that mitigates errors (e.g. auto-reloading on stale-chunk 'Failed to fetch dynamically imported module' errors after a deploy), the Sentry events still accumulate even though the mitigation works. The reload fires, users recover, but the issue count keeps climbing in Sentry.
handleErrorWithSentry calls captureException BEFORE invoking your wrapped callback (verified in @sentry/sveltekit build/esm/client/handleError.js — captureException(input.error, {mechanism:{type:'sveltekit'}}) runs first, then the user handler). So a mitigation inside handleError can never prevent the report. Suppression must happen in Sentry.init's beforeSend instead. Pattern for auto-reload mitigations: share the throttle state (e.g. a sessionStorage timestamp key) between beforeSend and handleError — beforeSend runs first during capture, so it can check 'was a reload already attempted recently?': if no, return null (drop the event; the reload that handleError is about to perform will fix it); if yes (error recurred within the throttle window, meaning reload did NOT fix it), let the event through tagged e.g. chunk_reload_failed=true. Gate the drop on event.exception.values[0].mechanism.type === 'sveltekit' so only navigation errors handled by handleError are suppressed, keeping telemetry for other capture paths.