-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix unwinding starting with a wrong Fiber on error in the complete phase #13237
Conversation
This currently fails the tests due to an unexpected warning.
The bug was caused by a structure like this: </Provider> </div> </errorInCompletePhase> We forgot to update nextUnitOfWork so it was still pointing at Provider when errorInCompletePhase threw. As a result, we would try to unwind from Provider (rather than from errorInCompletePhase), and thus pop the Provider twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we remove the workInProgress
parameter from completeUnitOfWork
entirely? Since it's always supposed to equal to nextUnitOfWork
.
current, | ||
workInProgress, | ||
nextRenderExpirationTime, | ||
); | ||
let next = nextUnitOfWork; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
next
is always null ever since we deleted call/return. Let's just remove the block below.
Oh I guess we don't because Flow :) Ok. |
Adds two regression tests (one for profiler stack and one for context stack). Also fixes the bug.
The bug was caused by a structure like this:
We forgot to update
nextUnitOfWork
(see the fix in the last commit). So it was still pointing atProvider
whenerrorInCompletePhase
threw. Normally we would update it right after so it wouldn't be noticeable, but in case of exception its value at the moment of throwing matters.As a result, we would try to unwind from
Provider
(rather than fromerrorInCompletePhase
), and thus pop theProvider
twice. It has already been popped at the beginning of the complete phase.This was easy to miss because a throwing complete phase is uncommon. But it can happen in host configs (e.g. RN nesting or DOM invalid style invariants).
I verified this fixes the original internal issue too.