Skip to content

Nested error boundaries break the devtools #245

Closed

Description

@c43721

When you have a layout route with a child route that has an error boundary, the devtools will error the page when trying to add the outlet-route route class to a dom node when the classList is an ErrorBoundary. This results in the page loading, then immediately erroring.

Error:

Oops!
Cannot read properties of undefined (reading 'add')

TypeError: Cannot read properties of undefined (reading 'add')
Image

I only ever see this with RenderErrorBoundary as the name of the fiber node. To be honest, I'm not sure where to dissect this further.

Activity

  1. c43721 commented on Jan 11, 2026

    @c43721
    Author

    https://github.com/c43721/rrdt-nested-errors-bug

    I found the reproduction. I've documented the steps in the readme here.

    To reproduce, I created a layout route with a single child. In that child route, export an error boundary. Then try to load that route. It will always error.

  2. c43721 commented on Jan 11, 2026

    @c43721
    Author

    It seems like it's not happy with the child error boundary, but the root one is always fine. When I tried to export an error boundary that's not in a nested layout file (in an Outlet for example) then it works perfectly fine. In my example, I documented both routes for clarity.

  3. changed the title [-]useReactTreeListener errors out during certain error boundary criterias[/-] [+]Nested error boundaries break the devtools[/+] on Jan 11, 2026
  4. AlemTuzlak commented on Jan 13, 2026

    @AlemTuzlak
    Contributor

    @c43721 wow that's wild, i'll see if i can fix that up, i'm looking into an issue with perf atm and i'll toss this into there as well!

  5. c43721 commented on Jan 13, 2026

    @c43721
    Author

    Thanks @AlemTuzlak. I would have offered to take it up but couldn't figure out the details quickly enough LOL

    Thanks for your attention!

  6. AlemTuzlak commented on Jan 14, 2026

    @AlemTuzlak
    Contributor

    should be fixed with latest release, mind confirming? @c43721

  7. c43721 commented on Jan 14, 2026

    @c43721
    Author

    @AlemTuzlak I can confirm this is closed and that #246 did fix it! Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions