Unhandled AbortError/InvalidStateError/TimeoutError from view transitions spamming Sentry

[froleo]

After enabling view transitions in our app a few months ago we have steadily getting unhandled-rejection errors in production from users on Chrome / Edge

Issue	Message	Last Seen	Age	Trend	Events	Users	Priority
Error	AbortError: Transition was skipped	58 min ago	4 mo	Ongoing	994	83	4
Error	InvalidStateError: Transition was aborted because of invalid state	6 hr ago	3 mo	Ongoing	159	47	1
Error	TimeoutError: Transition was aborted because of timeout in DOM update	1 wk ago	3 mo	Ongoing	12	10	–
AbortError	Old view transition aborted by new view transition.	3 wk ago	3 mo	Ongoing	4	2	–
InvalidStateError	Skipping view transition because document visibility state has become hidden.	4 wk ago	4 wk	Ongoing	1	1	–

Our router config:

const router = createRouter({
  routeTree,
  // ...
  defaultViewTransition: {
    types: ({ fromLocation, toLocation }) => {
    // fixes transition error when tab updates in background
      if (
        typeof document === "undefined" ||
        document.visibilityState !== "visible"
      ) {
        return false;
      }

      // Skip transition when only search params change
      if (fromLocation && fromLocation.pathname === toLocation.pathname) {
        return false;
      }
      return ["default"];
    },
  },
});

We also have a few pages with custom slide left/right transitions via links:

              <Link
                from={AuthRoute.fullPath}
                to="report/$id/edit"
                params={{ id: report.no }}
                viewTransition={{ types: ["slide-left"] }}
              />

Even with this guard in place, the errors keep happening.
The only "fix" i have found is to exclude these from Sentry, as they seem to be benign errors not noticeable to users
Is there a recommended way to handle this, or should i just silence the errors for now?

I was able to replicate Transition Aborted error on this Stackblitz, but only when the tab updates in the background. i.e having a preview tab open and making changes in the editor.

Related Links:

• facebook/react#34098
• Chrome issue 1
• Chrome issue2

[apoorva-01]

You're right that they're benign, and your types guard can't fully stop them. Here's why.

The router fires the transition and walks away. In router-core/src/router.ts it does document.startViewTransition(params) without keeping the returned ViewTransition object or attaching a .catch() to its .ready / .finished promises. So the moment a transition gets interrupted, that promise rejects with nothing listening, and it lands in Sentry as an unhandled rejection.

Your guard checks state at navigation start, but these rejections are about interruption timing, which happens later:

• a newer navigation skips the in-flight one → AbortError: Old view transition aborted...
• the tab goes hidden after the transition already started → InvalidStateError
• the DOM update overruns the 4s budget → TimeoutError

None of those are visible to the check you wrote, because at the point they fire the transition is already running.

Since the router owns that promise and doesn't hand it to you, there's no per-navigation hook to catch it yourself. The clean stopgap is a global handler that swallows exactly these:

window.addEventListener('unhandledrejection', (e) => {
  const err = e.reason
  if (
    err instanceof DOMException &&
    ['AbortError', 'InvalidStateError', 'TimeoutError'].includes(err.name) &&
    /transition/i.test(err.message)
  ) {
    e.preventDefault() // benign view-transition churn, don't report it
  }
})

preventDefault() keeps it out of Sentry and the console, and it's scoped tightly enough that a real error with the same name still gets through. If you'd rather keep it in Sentry config, the equivalent is ignoreErrors matching those messages, but the global listener is nicer since it covers anything else that reports errors too.

The actual fix belongs in the router: capture the ViewTransition and attach a .catch() on .finished so interrupted transitions resolve quietly. Worth opening an issue for that if there isn't one, but until then the handler above is safe to ship.

[MILLERMARRU]

This traces back to a real gap in the router's own view transition handling, not application code. In packages/router-core/src/router.ts, startViewTransition calls document.startViewTransition(...) and never stores or awaits the returned ViewTransition object:

document.startViewTransition(startViewTransitionParams)

The ViewTransition object exposes .ready, .finished, and .updateCallbackDone, each a promise the browser rejects in perfectly normal situations, a transition getting skipped, a newer transition superseding an older one, the tab going into the background mid-transition. Since nothing in the router attaches a .catch() to any of those promises, every one of those expected rejections becomes a genuine unhandled promise rejection, exactly what window.onunhandledrejection reports and what Sentry's default integration captures. The three messages here (AbortError: Transition was skipped, InvalidStateError, TimeoutError) are the literal browser spec rejection reasons for those promises, not application errors.

The types guard in the router config only controls whether a transition is attempted in the first place, it can't do anything about a transition that was legitimately started and then superseded or backgrounded.

Filtering them out in Sentry is a reasonable stopgap given the router doesn't guard against this itself. A more surgical version: attach a global capture before Sentry's own listener that swallows only rejections whose reason is one of these specific DOMException names when the message also matches this wording, then rethrow anything else, keeping real unrelated AbortErrors visible.

The durable fix belongs in the router itself though: wrapping the document.startViewTransition(...) call's returned promises with a no-op .catch() internally would stop this at the source for everyone using defaultViewTransition, since this isn't specific to this app's setup, it happens for any consumer as soon as two transitions race or the tab loses focus mid-transition. Worth filing as its own issue referencing this exact line, since the two issues linked here are about the browser's View Transition API itself, not this specific gap in how the router calls it.

[3ni8ma]

The AbortError/InvalidStateError/TimeoutError from view transitions is typically caused by the browser's navigation timing out during a document transition. The fix is to wrap your view transition logic:

import { startViewTransition } from "../utils/viewTransition"

if (typeof document !== "undefined" && "startViewTransition" in document) {
  try {
    const transition = document.startViewTransition(() => updateDOM())
    await transition.finished
  } catch (err) {
    if (err instanceof DOMException && err.name === "AbortError") {
      // View transition was superseded by another navigation — safe to ignore
      return
    }
    throw err
  }
}

TanStack Router's beforeLoad / onEnter can trigger these when navigations happen faster than the view transition completes. The router calls the previous transition's abort controller, which raises AbortError. This is expected behavior — the old transition is obsolete.

You can suppress Sentry noise by filtering in your beforeSend:

beforeSend(event) {
  if (event.exception?.values?.[0]?.type === "AbortError") return null
  return event
}