Repository navigation
fix(sentry): filter stale app chunk load errors - #1327
Conversation
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
tanstack-com | b092eed | Commit Preview URL Branch Preview URL |
Oct 17 2026, 01:30 PM |
|
This also suppresses failures that the reload handler does not recover from. I ran an isolated fixture against the current stale-app-reload module with in-memory session storage and a counted reload function: the first matching chunk error returned true and reloaded, the immediate second error returned false because of the 10-second throttle, but the isStaleAppError predicate used here still returned true for it. beforeSend would therefore discard that second failure even though no recovery was attempted. Please tie suppression to an error actually handled by recovery, and retain reporting when reload is throttled. A regression covering both outcomes would help keep repeated broken deployments visible. This was a module-level fixture, not a browser deployment reproduction. |
|
|
I added the narrower recovery check in b092eed. The error that triggers a reload can be dropped, while a new failure during the 10-second cooldown still reaches Sentry.
|
This PR addresses the frequent
TypeError: error loading dynamically imported moduleerrors reported to Sentry, specifically for assets likeNavbarAuthControls-CAfKNbeY.js.Problem: These errors are indicative of a "stale app" scenario (e.g., after a deployment or due to network issues), which
installStaleAppReloadHandlersalready attempts to mitigate by reloading the page. However, Sentry's globalonerrorhandler captures these errors before the reload mechanism can fully suppress them, leading to unnecessary error reports.Solution: The
beforeSendfunction insrc/router.tsxhas been updated to include a check usingisStaleAppErrorfromsrc/utils/stale-app-reload.ts. If an event's exception matches the patterns for stale app errors, the event is now filtered out (by returningnull), preventing it from being sent to Sentry.This change ensures that Sentry only receives actionable errors, while the client-side page reload behavior for stale app errors remains unchanged.
Fixes TANSTACK-COM-2E2
@sentry <feedback>: Autofix iterates on these changes@sentry stop iterating: Autofix stops iterating on this runThis PR was automatically generated by Sentry. You can adjust this setting at any time.