Improve error boundary handling for unmounted subtrees

[bvaughn]

A passive effect's cleanup function may throw after an unmount. Prior to this commit, such an error would be ignored. (React would not notify any error boundaries.) After this commit, React's behavior varies depending on which reconciler fork is being used.

Old reconciler fork

React will call componentDidCatch for the nearest unmounted error boundary (if there is one). If there are no unmounted error boundaries, React will still "swallow" the error because the return pointer has been disconnected so the normal error handling logic does not know how to traverse the tree to find the nearest still-mounted ancestor. (This behavior is not ideal, but it is temporary and will be replaced by the new fork.)

New reconciler fork

React will skip any unmounted boundaries and look for a still-mounted boundary. If one is found, it will call getDerivedStateFromError and/or componentDidCatch (depending on the type of boundary). Unmounted boundaries will be ignored, but as they have been unmounted– this seems appropriate.

Tests have been added for both reconciler variants. Note that syncing this change to www/fbsource might appear as a regression, because we may start logging errors that were previously ignored.

Open questions

• Is the temporary fix in the old reconciler worth it? Should we just let it swallow errors for now until the new fork gets merged again?
• Should we call gDSFE after an unmounted tree throws or should we only call cDC?
• Is this bug (potentially) bad enough to warrant a v16 bugfix release?

[acdlite]

Could you open the old fork changes separately? I have lots of Opinions™ on the new fork solution, whereas I'm not really picky about the old fork at all. And the old fork is more urgent, to unblock the RN sync.

[bvaughn]

There's two changes to the old fork:

1. Defer nulling out the stateNode field (so we don't throw).
2. Call componentDidCatch inside of the unmounted tree (if we find a boundary).

Which changes are you suggesting being split out? just the first? or both?

[acdlite]

Which changes are you suggesting being split out? just the first? or both?

Sorry, I phrased it ambiguously. What I meant was, let's focus on unblocking the RN sync first. So just patch the old fork so it no longer throws an internal error.

Then, once we've mitigated the blocker, we can return to addressing root cause. I'm suggesting we do that in a separate PR since that involves a semantic discussion and will take longer.

[bvaughn]

Sure. I was under the impression that folks wanted the full fix now. I'll post the smalller one separately.

[bvaughn]

Unblock PR #19543

[bvaughn]

Okay. I think I have a reasonable proposal. Take a look when you get the chance. 😄

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 3bfe779:

Sandbox	Source
React	Configuration

[gaearon]

skip any unmounted boundaries and look for a still-mounted boundary

I'm concerned this undermines the locality of error boundaries. For example, consider a buggy <FeedStoryCommentGifAttachment />. Luckily it's wrapped in an error boundary so even if it fails, the problem is isolated to that particular component inside a comment inside a story.

Now let's say we switch from Feed to Profile, and then the destroy handlers fire. There is a bug. But the closest common ancestor of <FeedStoryCommentGifAttachment /> and <Profile /> is <Router />. So even though the team "responsible" for the error are the folks maintaining the GIF renderer, it is the Profile that is being "penalized" by showing an error fallback over the whole page.

Arguably missing an error after unmount is not good. But by definition, since the component has unmounted, it means it isn't showing a broken UI. Therefore, I argue that it's not good to penalize non-broken UI that is perfectly capable of being rendered. We know it's not internally inconsistent — so why hide it?

Maybe there is a middle ground in that we don't set the gDSFE state, but we do call cDC for logging.

[bvaughn]

@gaearon Agreed that calling cDC only and ignoring gDSFE would be another reasonable proposal. Arguably better, although as Seb mentioned yesterday– there is some decreased pressure to fix errors that nobody "sees".

Fortunately, I think the component stack info (that's passed to componentDidCatch) makes it okay for us to call cDC on a higher (still-mounted) boundary. So the only question is about gDSFE.

[gaearon]

Yeah. Although there's a reason there's a decreased pressure if it doesn't lead to user-visible bugs. :-)

I think overall my intuition is that <CatchAll><Bug /></CatchAll> should always be safe to add without making the rest of your app behave in an unstable way. Otherwise it breaks encapsulation of responsibility.

[sebmarkbage]

An error that happens in renders are more ok to ignore because they’re not expected to have effects. In that case we can safely say that it’s better not to show the UI.

Errors that happen in effects are different though. They are expected to leave things in an inconsistent state.

There’s nothing to say that it’s actually isolated to that subtree. The unmount can affect other trees. Imaging refs or the similar thing in user space where the parent now has a reference to the deleted child.

React can’t really safely clean up even for mount or update effects by scoping it to the error boundary neither.

[bvaughn]

That's a good point.

If the effect did something like register/unregister itself with a common ancestor and it threw during unregistration, that could leave the larger app in a broken state (not confined to a subtree like an error thrown during render).

As you mention though, this affects mounts and updates too. So maybe that adds weight to the argument that we should at least match behaviors there (and call gDSFE too)?

Even if gDSFE isn't guaranteed to leave the app in a not-broken state, at least it makes the errors more in-your-face.

[sebmarkbage]

I think it’s at least a strong indicator that we must do something since it is a potentially really bad bug.

We could log only. However we know that there is a lot of variability in if logs are logged correctly, how seriously people follow up on logs or even if logging is done at all.

Also if we don’t show anything to the user, there isn’t something that indicates to the user that they should be careful. Like maybe they shouldn’t be so confident in future uses of the page or maybe they should reload.

I think that’s together is a pretty strong argument that the UI should change in some way. Now it could maybe change in other ways. Maybe there’s a way to isolate it or make it consistent. But seems like UI needs to change one way or another just to indicate that something on the page is not fully ok.

[bvaughn]

Is this bug (potentially) bad enough to warrant a v16 bugfix release?

I guess that would be a more difficult thing to do, since the real fix is only in the new reconciler fork.

[acdlite]

Is this bug (potentially) bad enough to warrant a v16 bugfix release?

My opinion is no, unless someone complains about it. It's been this way for a long time. It predates hooks even because errors inside componentWillUnmount raise the same semantic issue.

[bvaughn]

Yeah, I didn't think so– but it seemed worth discussing explicitly.

[sizebot]

Details of bundled changes.

Comparing: dab0854...3bfe779

react-dom

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
react-dom.development.js	+0.1%	+0.1%	876.9 KB	877.66 KB	200.81 KB	201.03 KB	NODE_DEV
ReactDOMForked-prod.js	🔺+0.2%	🔺+0.2%	391.18 KB	392.16 KB	71.95 KB	72.09 KB	FB_WWW_PROD
react-dom.production.min.js	🔺+0.1%	0.0%	119.27 KB	119.39 KB	38.32 KB	38.33 KB	NODE_PROD
ReactDOMForked-profiling.js	+0.2%	+0.2%	406.24 KB	407.16 KB	74.65 KB	74.79 KB	FB_WWW_PROFILING
react-dom-test-utils.production.min.js	0.0%	-0.0%	12.86 KB	12.86 KB	5.04 KB	5.04 KB	UMD_PROD
ReactDOMTesting-dev.js	+0.1%	+0.1%	949.1 KB	949.91 KB	212.66 KB	212.86 KB	FB_WWW_DEV
ReactDOMTesting-prod.js	🔺+0.1%	🔺+0.1%	391.82 KB	392.14 KB	73.36 KB	73.41 KB	FB_WWW_PROD
react-dom.development.js	+0.1%	+0.1%	921.34 KB	922.12 KB	203.3 KB	203.49 KB	UMD_DEV
react-dom.production.min.js	🔺+0.1%	0.0%	119.22 KB	119.33 KB	38.97 KB	38.98 KB	UMD_PROD
react-dom.profiling.min.js	+0.1%	+0.1%	123.12 KB	123.23 KB	40.19 KB	40.23 KB	UMD_PROFILING
ReactDOMForked-dev.js	0.0%	+0.1%	993.56 KB	994.05 KB	220.1 KB	220.21 KB	FB_WWW_DEV
react-dom.profiling.min.js	+0.1%	0.0%	123.34 KB	123.46 KB	39.58 KB	39.59 KB	NODE_PROFILING
ReactDOM-dev.js	+0.1%	+0.1%	986.35 KB	987.16 KB	219.12 KB	219.31 KB	FB_WWW_DEV
ReactDOM-prod.js	🔺+0.1%	🔺+0.1%	388.2 KB	388.52 KB	71.25 KB	71.3 KB	FB_WWW_PROD
ReactDOM-profiling.js	+0.1%	+0.1%	402.39 KB	402.71 KB	73.91 KB	73.95 KB	FB_WWW_PROFILING
ReactDOMServer-dev.js	0.0%	0.0%	146.97 KB	146.97 KB	37.34 KB	37.34 KB	FB_WWW_DEV
ReactDOMServer-prod.js	0.0%	-0.0%	47.3 KB	47.3 KB	11.04 KB	11.04 KB	FB_WWW_PROD
react-dom-test-utils.development.js	0.0%	-0.0%	65.86 KB	65.86 KB	18.17 KB	18.17 KB	UMD_DEV

react-art

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
ReactART-prod.js	🔺+0.1%	🔺+0.1%	243.91 KB	244.24 KB	43 KB	43.05 KB	FB_WWW_PROD
react-art.development.js	+0.1%	+0.1%	666.11 KB	666.89 KB	141.98 KB	142.17 KB	UMD_DEV
react-art.production.min.js	🔺+0.1%	🔺+0.1%	109.66 KB	109.78 KB	33.95 KB	33.97 KB	UMD_PROD
react-art.development.js	+0.1%	+0.2%	568.49 KB	569.24 KB	124.23 KB	124.44 KB	NODE_DEV
react-art.production.min.js	🔺+0.2%	🔺+0.1%	74.62 KB	74.74 KB	23.12 KB	23.15 KB	NODE_PROD
ReactART-dev.js	+0.1%	+0.2%	632.26 KB	633.07 KB	134.25 KB	134.46 KB	FB_WWW_DEV

react-native-renderer

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
ReactNativeRenderer-dev.js	+0.1%	+0.2%	684.43 KB	685.24 KB	148.3 KB	148.53 KB	RN_FB_DEV
ReactFabric-dev.js	+0.1%	+0.2%	665.15 KB	665.96 KB	143.66 KB	143.89 KB	RN_FB_DEV
ReactNativeRenderer-dev.js	+0.1%	+0.2%	679.04 KB	679.85 KB	147.45 KB	147.67 KB	RN_OSS_DEV
ReactFabric-prod.js	🔺+0.1%	🔺+0.1%	265.64 KB	265.96 KB	47.06 KB	47.09 KB	RN_FB_PROD
ReactNativeRenderer-prod.js	🔺+0.1%	🔺+0.1%	271.84 KB	272.16 KB	48.34 KB	48.39 KB	RN_OSS_PROD
ReactFabric-profiling.js	+0.1%	+0.1%	276.99 KB	277.31 KB	49.24 KB	49.29 KB	RN_FB_PROFILING
ReactNativeRenderer-profiling.js	+0.1%	+0.1%	283.33 KB	283.66 KB	50.52 KB	50.57 KB	RN_OSS_PROFILING
ReactNativeRenderer-prod.js	🔺+0.1%	🔺+0.1%	271.79 KB	272.12 KB	48.33 KB	48.37 KB	RN_FB_PROD
ReactNativeRenderer-profiling.js	+0.1%	+0.1%	283.29 KB	283.61 KB	50.5 KB	50.55 KB	RN_FB_PROFILING
ReactFabric-dev.js	+0.1%	+0.2%	659.75 KB	660.56 KB	142.8 KB	143.03 KB	RN_OSS_DEV
ReactFabric-prod.js	🔺+0.1%	🔺+0.1%	265.67 KB	265.99 KB	47.07 KB	47.1 KB	RN_OSS_PROD
ReactFabric-profiling.js	+0.1%	+0.1%	277.03 KB	277.35 KB	49.26 KB	49.31 KB	RN_OSS_PROFILING

react-reconciler

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
react-reconciler.development.js	+0.1%	+0.2%	624.25 KB	625 KB	133.89 KB	134.1 KB	NODE_DEV
react-reconciler.production.min.js	🔺+0.1%	🔺+0.1%	84.1 KB	84.22 KB	25.85 KB	25.87 KB	NODE_PROD

react-test-renderer

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
react-test-renderer.development.js	+0.1%	+0.1%	604.6 KB	605.38 KB	127.26 KB	127.45 KB	UMD_DEV
react-test-renderer.production.min.js	🔺+0.1%	🔺+0.1%	76.79 KB	76.9 KB	24.01 KB	24.02 KB	UMD_PROD
react-test-renderer.development.js	+0.1%	+0.2%	576.01 KB	576.77 KB	125.81 KB	126.02 KB	NODE_DEV
react-test-renderer.production.min.js	🔺+0.1%	🔺+0.1%	76.6 KB	76.72 KB	23.72 KB	23.74 KB	NODE_PROD
ReactTestRenderer-dev.js	+0.1%	+0.2%	591.34 KB	592.14 KB	126.97 KB	127.19 KB	FB_WWW_DEV
ReactTestRenderer-dev.js	+0.1%	+0.2%	585.99 KB	586.8 KB	126.7 KB	126.91 KB	RN_FB_DEV
ReactTestRenderer-prod.js	🔺+0.1%	🔺+0.1%	231.22 KB	231.54 KB	42.03 KB	42.08 KB	RN_FB_PROD
ReactTestRenderer-profiling.js	+0.1%	+0.1%	242.61 KB	242.93 KB	44.19 KB	44.24 KB	RN_FB_PROFILING

ReactDOM: size: 0.0%, gzip: -0.0%

Size changes (stable)

Generated by 🚫 dangerJS against 3bfe779

[bvaughn]

Ping 😄 Can I get a review?

[sebmarkbage]

I acknowledge your desire and will attempt to look at this, this afternoon. If I don’t, feel free to message me directly at an uncomfortable time of the day.

[bvaughn]

When would the most uncomfortable time of day be, for you? 😇

[bvaughn]

Okay Seb. Back to you.

[bvaughn]

Not sure why DOMPluginEventSystem-test.internal.js test started failing after I merged master into my branch. Seems like that should be unrelated. Will dig in...

[bvaughn]

Ooh. I think this PR actually catches a legit error from one of our other tests 😄

One of the DOM plugin event system tests calls its click handles during unmount without any params:

react/packages/react-dom/src/events/__tests__/DOMPluginEventSystem-test.internal.js

Lines 1676 to 1679 in ccb6c39

	setClick1();
	setClick2();
	setClick3();
	setClick4();

Which triggers an invariant that we were (before) just ignoring:

react/packages/react-dom/src/client/ReactDOMEventHandle.js

Lines 206 to 214 in ccb6c39

	return (
	target: EventTarget | ReactScopeInstance,
	callback: (SyntheticEvent<EventTarget>) => void,
	) => {
	invariant(
	typeof callback === 'function',
	'ReactDOM.createEventHandle: setter called with an invalid ' +
	'callback. The callback must be a function.',
	);

[bvaughn]

This is the main fix for the new fork. The rest of the changes were just to funnel this fiber through.

[bvaughn]

This test covers the error-boundary-as-immediate-parent case.

[sebmarkbage]

Looks great!

[bvaughn]

Thanks!

[acdlite]

This fix looks great!

We should add the same behavior for errors thrown in componentWillUnmount, too. It'll be the same fix: in commitUnmount, pass the parent of the nearest mounted boundary, instead of current.return:

react/packages/react-reconciler/src/ReactFiberCommitWork.new.js

Line 1004 in ffb749c

safelyCallDestroy(current, current.return, destroy);

[bvaughn]

Thanks @acdlite.

I'm not aware of this being a problem for cWU, since we have not yet disconnected the return pointer at that point (cWU is called by commitDeletion before it calls detachFiberMutation). So errors thrown in cWU can still walk the return path to find the nearest boundary (the same as layout effects can).

Am I mistaken about something?

Edit 1: Oh I believe what you're suggesting is that we should make this change so that if the nearest error boundary happens to be one we are about to unmount– we'll skip over it. In which case, yes! That's a good suggestion. I'll be happy to make the change on Monday.

Edit 2: Seems like we should get that change into v17 along with the passive effects change, so we're consistent. I'll make it on Monday.