fix(system): recover from transient null-data crashes during route navigation

[dzucconi]

So, I wired up the Sentry MCP and was exploring errors. A big class is comprised of null access errors (Cannot read properties of null (reading '...'), etc). After fixing a few of these, I noticed the same pattern repeating itself: we were accessing a property on a type that Metaphysics reports as non-nullable. This is unusual and typically should 404, because they tend to be principal fields. The fact that they were coming up null some of the time suggests some other problem rather than them being null at fetch and rendering anyway.

It seems that during a client-side route transition the component can be re-rendered for a moment with that data null, and it throws. Today ContentErrorBoundary catches the throw, flashes the "Something Went Wrong" page mid-navigation, and reports it to Sentry, even though the app recovers when the next route commits. This is a property of how the router keeps the outgoing page mounted during the pending transition while Relay store activity briefly resolves the principal field to null.

This is a weird one to fix, as it seems like ultimately it originates from within found-relay (see trade-offs, below).

Ultimately this treats the symptom for now. We introduce a new error boundary, TransientRouteErrorBoundary, between ContentErrorBoundary and the route content in AppShell. It owns only this transient-recovery concern.

• Mid-navigation crash (the live URL has already advanced, but the boundary's committed pathname prop, frozen by the router's StaticContainer during the pending transition, still points at the route we're leaving): treat it as a transient teardown. Render nothing and recover automatically when the next route commits. (No error page, no Sentry reporting).

• Everything else (genuine errors on the current page, HttpErrors, chunk-load failures): re-thrown to ContentErrorBoundary, which is unchanged and still owns all error UI + Sentry reporting. Errors surface immediately.

These are the types of issues that this should mitigate:

• Cannot read properties of null …
• null is not an object …
• … as it is null

Possibly addressed (a null-guarded component renders a different number of hooks; mitigated only when mid-navigation):

• Rendered fewer hooks than expected …

Trade-offs

• This catches the transient at the boundary rather than preventing the null at the data layer. The exact operation that publishes the null principal field isn't pinned down (it would need runtime store instrumentation and likely a found-relay patch); the boundary neutralizes the whole class regardless of the precise trigger.
• Some genuine errors may go unreported. A real error that the user navigates away from within the transition looks identical to a transient and won't be reported.

After deploy

Watch errorBoundary:content "Cannot read properties of null" and the Safari null is not an object variant. Transient navigation nulls should drop; genuine same-page crashes should still report.

cc @artsy/diamond-devs

[dzucconi]

It should be noted that I'm sort of indifferent about this fix. I don't love that this is just dealing with the symptom of a deeper issue in our router.

[rabidpaul]

I'm also hesitant to swallow any errors. You've documented this well, but I'd feel better if we had a plan to investigate and solve the root problem, or even had a lead on what the medium-term fix should be. Can we create an investigation ticket with one or more decent root cause paths to look at?

[mzikherman]

I'm cool with this because I think our router/SSR/all-the-things setup on Force is rather complex but also agree this is a 'blunt fix' w/o understanding the true cause.

But also...I'm fine with it either way 😆