Uh oh!
There was an error while loading. Please reload this page.
[enableInfiniteRenderLoopDetection] Warn about potential infinite loop, instead of interrupting - #35999
Merged
Conversation
Comparing: 3f0b9e6...6e4f4e4 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show |
hoxyqforce-pushed
the
reconciler/warn-about-potential-infinite-render-loop
branch
2 times, most recently
from
March 11, 2026 01:25
6f027a3 to
ea77284Compare| 'follow the stack trace as described in https://react.dev/link/setstate-in-render\n' + | ||
| ' in App (at **)', | ||
| ]); | ||
| const originalConsoleError = console.error; |
Contributor
There was a problem hiding this comment.
Can you use assertConsoleErrorDev instead?
CollaboratorAuthor
There was a problem hiding this comment.
No, because I am patching a console not to just intercept the message, but to wait for the specific console.error call, pass the test and avoid being stuck in an infinite loop.
I could use assertConsoleErrorDev to validate that the message was logged, but waiting for the message already implies that check.
| // hydration lanes in this check, because render triggered by selective | ||
| // hydration is conceptually not an update. | ||
| if ( | ||
| // Was the finished render the result of an update (not hydration)? |
Contributor
There was a problem hiding this comment.
Why did we remove the feature flag gating?
CollaboratorAuthor
There was a problem hiding this comment.
This is pre-existing check that was already passing in some scenarios, when the update could be tracked through lanes. Like obvious cases where we schedule the infinite loop inside a single component, causing it to loop on itself.
This is outside of the enableInfiniteRenderLoopDetection feature flag, so the goal here is to keep it as it is, while making the new detection logic non-fatal to get some signal.
Uh oh!
There was an error while loading. Please reload this page.
hoxyqforce-pushed
the
reconciler/warn-about-potential-infinite-render-loop
branch
from
March 16, 2026 16:32
ea77284 to
08d9733Compare| it("does not infinite loop if there's a synchronous render phase update on another component", async () => { | ||
| if (gate(flags => !flags.enableInfiniteRenderLoopDetection)) { | ||
| it("warns about potential infinite loop if there's a synchronous render phase update on another component", async () => { | ||
| if (!__DEV__ || gate(flags => !flags.enableInfiniteRenderLoopDetection)) { |
CollaboratorAuthor
There was a problem hiding this comment.
With @gate, it also checks that the test fails on assertions when gating conditions are not met, but it will just go infinite loop, and it will considered as failed run, not failed assertion. There is a TODO to convert some other tests in this file:
https://github.com/facebook/react/blob/6e4f4e4d169256bf77ee88c5f88ab5d26c260f3f/packages/react-dom/src/__tests__/ReactUpdates-test.js#L1871
I think there is a way to convert to gate prama these tests, but it would require more attention
rickhanlonii
approved these changes
Mar 17, 2026
…p, instead of interrupting
hoxyqforce-pushed
the
reconciler/warn-about-potential-infinite-render-loop
branch
from
March 18, 2026 14:03
08d9733 to
6e4f4e4CompareUh oh!
There was an error while loading. Please reload this page.
github-actionsBot
pushed a commit
that referenced
this pull request
Mar 18, 2026
…p, instead of interrupting (#35999) The `enableInfiniteRenderLoopDetection` feature flag is currently disabled everywhere. When attempted to roll out this at Meta, we've observed multiple false-positives, where counter-based approach would interrupt the render that would've resolved at some later iteration. This change gates the scenarios that are only discovered with the instrumentation behind `enableInfiniteRenderLoopDetection` flag to warn about potential infinite loop, instead of throwing an error and hitting an error boundary. The main reason is to see if we can a signal on which possible area of scenarios this new approach to infinite loops covers. The gist of the approach is to ensure that we are still throwing error and breaking the infinite loop, if we were doing this without `enableInfiniteRenderLoopDetection` feature flag enabled. This will log multiple errors if there is an infinite loop, but this should be fine, and it also aligns with the pattern for warnings about passive effects infinite loop. I've validated that tests in `ReactUpdates-test.js` are passing independently whether the feature flag is enabled or not. DiffTrain build for [b4546cd](b4546cd)
github-actionsBot
pushed a commit
that referenced
this pull request
Mar 18, 2026
…p, instead of interrupting (#35999) The `enableInfiniteRenderLoopDetection` feature flag is currently disabled everywhere. When attempted to roll out this at Meta, we've observed multiple false-positives, where counter-based approach would interrupt the render that would've resolved at some later iteration. This change gates the scenarios that are only discovered with the instrumentation behind `enableInfiniteRenderLoopDetection` flag to warn about potential infinite loop, instead of throwing an error and hitting an error boundary. The main reason is to see if we can a signal on which possible area of scenarios this new approach to infinite loops covers. The gist of the approach is to ensure that we are still throwing error and breaking the infinite loop, if we were doing this without `enableInfiniteRenderLoopDetection` feature flag enabled. This will log multiple errors if there is an infinite loop, but this should be fine, and it also aligns with the pattern for warnings about passive effects infinite loop. I've validated that tests in `ReactUpdates-test.js` are passing independently whether the feature flag is enabled or not. DiffTrain build for [b4546cd](b4546cd)
This was referenced Mar 18, 2026
github-actionsBot
pushed a commit
to code/lib-react
that referenced
this pull request
Mar 21, 2026
…p, instead of interrupting (react#35999) The `enableInfiniteRenderLoopDetection` feature flag is currently disabled everywhere. When attempted to roll out this at Meta, we've observed multiple false-positives, where counter-based approach would interrupt the render that would've resolved at some later iteration. This change gates the scenarios that are only discovered with the instrumentation behind `enableInfiniteRenderLoopDetection` flag to warn about potential infinite loop, instead of throwing an error and hitting an error boundary. The main reason is to see if we can a signal on which possible area of scenarios this new approach to infinite loops covers. The gist of the approach is to ensure that we are still throwing error and breaking the infinite loop, if we were doing this without `enableInfiniteRenderLoopDetection` feature flag enabled. This will log multiple errors if there is an infinite loop, but this should be fine, and it also aligns with the pattern for warnings about passive effects infinite loop. I've validated that tests in `ReactUpdates-test.js` are passing independently whether the feature flag is enabled or not. DiffTrain build for [b4546cd](react@b4546cd)
github-actionsBot
pushed a commit
to code/lib-react
that referenced
this pull request
Mar 21, 2026
…p, instead of interrupting (react#35999) The `enableInfiniteRenderLoopDetection` feature flag is currently disabled everywhere. When attempted to roll out this at Meta, we've observed multiple false-positives, where counter-based approach would interrupt the render that would've resolved at some later iteration. This change gates the scenarios that are only discovered with the instrumentation behind `enableInfiniteRenderLoopDetection` flag to warn about potential infinite loop, instead of throwing an error and hitting an error boundary. The main reason is to see if we can a signal on which possible area of scenarios this new approach to infinite loops covers. The gist of the approach is to ensure that we are still throwing error and breaking the infinite loop, if we were doing this without `enableInfiniteRenderLoopDetection` feature flag enabled. This will log multiple errors if there is an infinite loop, but this should be fine, and it also aligns with the pattern for warnings about passive effects infinite loop. I've validated that tests in `ReactUpdates-test.js` are passing independently whether the feature flag is enabled or not. DiffTrain build for [b4546cd](react@b4546cd)
hoxyq added a commit
that referenced
this pull request
Apr 13, 2026
…initeRenderLoopDetection (#36195) My change in #35999 did not cover all possible scenarios for emitting a warning, instead of throwing. The instrumentation not only enables the identification for the infinite loop via execution context checks, but also adds the check to more lifecycle methods, like `markRootPinged` and `markRootUpdated`. See the newly added test to understand a potential scenario. Before the fix, the error would be thrown: <img width="1192" height="424" alt="Screenshot 2026-04-08 at 17 21 51" src="https://github.com/user-attachments/assets/ba8ea379-0271-4938-ae45-e37ee75e1963" /> With the current changes, the warning is logged with `console.error`.
github-actionsBot
pushed a commit
that referenced
this pull request
Apr 13, 2026
…initeRenderLoopDetection (#36195) My change in #35999 did not cover all possible scenarios for emitting a warning, instead of throwing. The instrumentation not only enables the identification for the infinite loop via execution context checks, but also adds the check to more lifecycle methods, like `markRootPinged` and `markRootUpdated`. See the newly added test to understand a potential scenario. Before the fix, the error would be thrown: <img width="1192" height="424" alt="Screenshot 2026-04-08 at 17 21 51" src="https://github.com/user-attachments/assets/ba8ea379-0271-4938-ae45-e37ee75e1963" /> With the current changes, the warning is logged with `console.error`. DiffTrain build for [fef12a0](fef12a0)
github-actionsBot
pushed a commit
that referenced
this pull request
Apr 13, 2026
…initeRenderLoopDetection (#36195) My change in #35999 did not cover all possible scenarios for emitting a warning, instead of throwing. The instrumentation not only enables the identification for the infinite loop via execution context checks, but also adds the check to more lifecycle methods, like `markRootPinged` and `markRootUpdated`. See the newly added test to understand a potential scenario. Before the fix, the error would be thrown: <img width="1192" height="424" alt="Screenshot 2026-04-08 at 17 21 51" src="https://github.com/user-attachments/assets/ba8ea379-0271-4938-ae45-e37ee75e1963" /> With the current changes, the warning is logged with `console.error`. DiffTrain build for [fef12a0](fef12a0)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
enableInfiniteRenderLoopDetectionfeature flag is currently disabled everywhere. When attempted to roll out this at Meta, we've observed multiple false-positives, where counter-based approach would interrupt the render that would've resolved at some later iteration.This change gates the scenarios that are only discovered with the instrumentation behind
enableInfiniteRenderLoopDetectionflag to warn about potential infinite loop, instead of throwing an error and hitting an error boundary. The main reason is to see if we can a signal on which possible area of scenarios this new approach to infinite loops covers.The gist of the approach is to ensure that we are still throwing error and breaking the infinite loop, if we were doing this without
enableInfiniteRenderLoopDetectionfeature flag enabled.This will log multiple errors if there is an infinite loop, but this should be fine, and it also aligns with the pattern for warnings about passive effects infinite loop.
I've validated that tests in
ReactUpdates-test.jsare passing independently whether the feature flag is enabled or not.