Detect crashes caused by Async Client Components #27019
Merged
+145
−1
Conversation
This file contains 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
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: a1c62b8...439ca59 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 |
acdlite
force-pushed
the
detect-async-component-crash
branch
2 times, most recently
from
18fced0
to
f40e936
Compare
Comment on lines
1995
to
1998
| 'async/await is not yet supported in Client Components, ' + | ||
| 'only Server Components. This error is often caused by ' + | ||
| "accidentally adding `'use client'` to a module that " + | ||
| 'was originally written for the server.', |
There was a problem hiding this comment.
Suggested change
| 'async/await is not yet supported in Client Components, ' + | |
| 'only Server Components. This error is often caused by ' + | |
| "accidentally adding `'use client'` to a module that " + | |
| 'was originally written for the server.', | |
| 'Detected an infinite suspense loop while, ' + | |
| 'rendering the app shell. This error is often caused by ' + | |
| "accidentally adding `'use client'` to a module that " + | |
| 'was originally written for the server.', |
There was a problem hiding this comment.
I wanted the message to focus on the mistake that led to the crash. The fact that falls into a loop is an implementation detail; the reason for the error is we just don't support this feature yet.
Is the reason for the suggestion because technically there are other ways the error might occur besides async/await?
sebmarkbage
approved these changes
Jun 28, 2023
acdlite
force-pushed
the
detect-async-component-crash
branch
4 times, most recently
from
8819a4f
to
4848659
Compare
Suspending with an uncached promise is not yet supported. We only support suspending on promises that are cached between render attempts. (We do plan to partially support this in the future, at least in certain constrained cases, like during a route transition.) This includes the case where a component returns an uncached promise, which is effectively what happens if a Client Component is authored using async/await syntax. This is an easy mistake to make in a Server Components app, because async/await _is_ available in Server Components. In the current behavior, this can sometimes cause the app to crash with an infinite loop, because React will repeatedly keep trying to render the component, which will result in a fresh promise, which will result in a new render attempt, and so on. We have some strategies we can use to prevent this — during a concurrent render, we can suspend the work loop until the promise resolves. If it's not a concurrent render, we can show a Suspense fallback and try again at concurrent priority. There's one case where neither of these strategies work, though: during a sync render when there's no parent Suspense boundary. (We refer to this as the "shell" of the app because it exists outside of any loading UI.) Since we don't have any great options for this scenario, we should at least error gracefully instead of crashing the app. So this commit adds a detection mechanism for render loops caused by async client components. The way it works is, if an app suspends repeatedly in the shell during a synchronous render, without committing anything in between, we will count the number of attempts and eventually trigger an error once the count exceeds a threshold. In the future, we will consider ways to make this case a warning instead of a hard error. See facebook#26801 for more details.
acdlite
force-pushed
the
detect-async-component-crash
branch
from
4848659
to
439ca59
Compare
github-actions bot
pushed a commit
that referenced
this pull request
Jun 29, 2023
Suspending with an uncached promise is not yet supported. We only support suspending on promises that are cached between render attempts. (We do plan to partially support this in the future, at least in certain constrained cases, like during a route transition.) This includes the case where a component returns an uncached promise, which is effectively what happens if a Client Component is authored using async/await syntax. This is an easy mistake to make in a Server Components app, because async/await _is_ available in Server Components. In the current behavior, this can sometimes cause the app to crash with an infinite loop, because React will repeatedly keep trying to render the component, which will result in a fresh promise, which will result in a new render attempt, and so on. We have some strategies we can use to prevent this — during a concurrent render, we can suspend the work loop until the promise resolves. If it's not a concurrent render, we can show a Suspense fallback and try again at concurrent priority. There's one case where neither of these strategies work, though: during a sync render when there's no parent Suspense boundary. (We refer to this as the "shell" of the app because it exists outside of any loading UI.) Since we don't have any great options for this scenario, we should at least error gracefully instead of crashing the app. So this commit adds a detection mechanism for render loops caused by async client components. The way it works is, if an app suspends repeatedly in the shell during a synchronous render, without committing anything in between, we will count the number of attempts and eventually trigger an error once the count exceeds a threshold. In the future, we will consider ways to make this case a warning instead of a hard error. See #26801 for more details. DiffTrain build for [fc80111](fc80111)
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jun 30, 2023
Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jun 30, 2023
Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jun 30, 2023
Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jun 30, 2023
Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jul 2, 2023
Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jul 2, 2023
Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
acdlite
added a commit
that referenced
this pull request
Jul 2, 2023
…#27031) Adds a development warning to complement the error introduced by #27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in #27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
github-actions bot
pushed a commit
that referenced
this pull request
Jul 2, 2023
…#27031) Adds a development warning to complement the error introduced by #27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in #27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.) DiffTrain build for [5c8dabf](5c8dabf)
timneutkens
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 4, 2023
This PR updates the vendored react dependencies using `pnpm sync-react` ### React upstream changes - facebook/react#27028 - facebook/react#27027 - facebook/react#27019 - facebook/react#26954 - facebook/react#26987 - facebook/react#26985 - facebook/react#26933 - facebook/react#26625 - facebook/react#27011 - facebook/react#27008 - facebook/react#26997 - facebook/react#26989 - facebook/react#26955 - facebook/react#26963 - facebook/react#26983 - facebook/react#26914 - facebook/react#26951 - facebook/react#26977 - facebook/react#26958 - facebook/react#26940 - facebook/react#26939 - facebook/react#26887 - facebook/react#26947 - facebook/react#26945 - facebook/react#26942 - facebook/react#26938 - facebook/react#26844 - facebook/react#25510 - facebook/react#26932 - facebook/react#26896 - facebook/react#26913 - facebook/react#26888 - facebook/react#26827 - facebook/react#26889 - facebook/react#26877 - facebook/react#26873 - facebook/react#26880 - facebook/react#26842 - facebook/react#26858 - facebook/react#26754 - facebook/react#26753 - facebook/react#26881 ### Related Closes #49409 (by facebook/react#26977) fix NEXT-1189 Co-authored-by: Shu Ding <g@shud.in>
timneutkens
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 6, 2023
Fixes #49409 ### React upstream changes - facebook/react#27045 - facebook/react#27051 - facebook/react#27032 - facebook/react#27031 - facebook/react#27029 - facebook/react#27028 - facebook/react#27027 - facebook/react#27019 - facebook/react#26954 - facebook/react#26987 - facebook/react#26985 - facebook/react#26933 - facebook/react#26625 - facebook/react#27011 - facebook/react#27008 - facebook/react#26997 - facebook/react#26989 - facebook/react#26955 - facebook/react#26963 - facebook/react#26983 - facebook/react#26914 - facebook/react#26951 - facebook/react#26977 - facebook/react#26958 - facebook/react#26940 - facebook/react#26939 - facebook/react#26887 - facebook/react#26947 - facebook/react#26945 - facebook/react#26942 - facebook/react#26938 - facebook/react#26844 - facebook/react#25510 - facebook/react#26932 - facebook/react#26896 - facebook/react#26913 - facebook/react#26888 - facebook/react#26827 - facebook/react#26889 - facebook/react#26877 - facebook/react#26873 - facebook/react#26880 - facebook/react#26842 - facebook/react#26858 - facebook/react#26754 - facebook/react#26753 - facebook/react#26881 --------- Co-authored-by: Jiachi Liu <inbox@huozhi.im>
shuding
added a commit
to vercel/next.js
that referenced
this pull request
Jul 8, 2023
This PR updates the vendored react dependencies using `pnpm sync-react` ### React upstream changes - facebook/react#27028 - facebook/react#27027 - facebook/react#27019 - facebook/react#26954 - facebook/react#26987 - facebook/react#26985 - facebook/react#26933 - facebook/react#26625 - facebook/react#27011 - facebook/react#27008 - facebook/react#26997 - facebook/react#26989 - facebook/react#26955 - facebook/react#26963 - facebook/react#26983 - facebook/react#26914 - facebook/react#26951 - facebook/react#26977 - facebook/react#26958 - facebook/react#26940 - facebook/react#26939 - facebook/react#26887 - facebook/react#26947 - facebook/react#26945 - facebook/react#26942 - facebook/react#26938 - facebook/react#26844 - facebook/react#25510 - facebook/react#26932 - facebook/react#26896 - facebook/react#26913 - facebook/react#26888 - facebook/react#26827 - facebook/react#26889 - facebook/react#26877 - facebook/react#26873 - facebook/react#26880 - facebook/react#26842 - facebook/react#26858 - facebook/react#26754 - facebook/react#26753 - facebook/react#26881 ### Related Closes #49409 (by facebook/react#26977) fix NEXT-1189 Co-authored-by: Shu Ding <g@shud.in>
jerrydev0927
added a commit
to jerrydev0927/react
that referenced
this pull request
Jan 5, 2024
… (#27031) Adds a development warning to complement the error introduced by facebook/react#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook/react#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.) DiffTrain build for [5c8dabf8864e1d826c831d6096b2dfa66309961a](facebook/react@5c8dabf)
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
Suspending with an uncached promise is not yet supported. We only support suspending on promises that are cached between render attempts. (We do plan to partially support this in the future, at least in certain constrained cases, like during a route transition.) This includes the case where a component returns an uncached promise, which is effectively what happens if a Client Component is authored using async/await syntax. This is an easy mistake to make in a Server Components app, because async/await _is_ available in Server Components. In the current behavior, this can sometimes cause the app to crash with an infinite loop, because React will repeatedly keep trying to render the component, which will result in a fresh promise, which will result in a new render attempt, and so on. We have some strategies we can use to prevent this — during a concurrent render, we can suspend the work loop until the promise resolves. If it's not a concurrent render, we can show a Suspense fallback and try again at concurrent priority. There's one case where neither of these strategies work, though: during a sync render when there's no parent Suspense boundary. (We refer to this as the "shell" of the app because it exists outside of any loading UI.) Since we don't have any great options for this scenario, we should at least error gracefully instead of crashing the app. So this commit adds a detection mechanism for render loops caused by async client components. The way it works is, if an app suspends repeatedly in the shell during a synchronous render, without committing anything in between, we will count the number of attempts and eventually trigger an error once the count exceeds a threshold. In the future, we will consider ways to make this case a warning instead of a hard error. See facebook#26801 for more details.
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
…facebook#27031) Adds a development warning to complement the error introduced by facebook#27019. We can detect and warn about async client components by checking the prototype of the function. This won't work for environments where async functions are transpiled, but for native async functions, it allows us to log an earlier warning during development, including in cases that don't trigger the infinite loop guard added in facebook#27019. It does not supersede the infinite loop guard, though, because that mechanism also prevents the app from crashing. I also added a warning for calling a hook inside an async function. This one fires even during a transition. We could add a corresponding warning to Flight, since hooks are not allowed in async Server Components, either. (Though in both environments, this is better handled by a lint rule.)
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
Suspending with an uncached promise is not yet supported. We only support suspending on promises that are cached between render attempts. (We do plan to partially support this in the future, at least in certain constrained cases, like during a route transition.) This includes the case where a component returns an uncached promise, which is effectively what happens if a Client Component is authored using async/await syntax. This is an easy mistake to make in a Server Components app, because async/await _is_ available in Server Components. In the current behavior, this can sometimes cause the app to crash with an infinite loop, because React will repeatedly keep trying to render the component, which will result in a fresh promise, which will result in a new render attempt, and so on. We have some strategies we can use to prevent this — during a concurrent render, we can suspend the work loop until the promise resolves. If it's not a concurrent render, we can show a Suspense fallback and try again at concurrent priority. There's one case where neither of these strategies work, though: during a sync render when there's no parent Suspense boundary. (We refer to this as the "shell" of the app because it exists outside of any loading UI.) Since we don't have any great options for this scenario, we should at least error gracefully instead of crashing the app. So this commit adds a detection mechanism for render loops caused by async client components. The way it works is, if an app suspends repeatedly in the shell during a synchronous render, without committing anything in between, we will count the number of attempts and eventually trigger an error once the count exceeds a threshold. In the future, we will consider ways to make this case a warning instead of a hard error. See #26801 for more details. DiffTrain build for commit fc80111.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Suspending with an uncached promise is not yet supported. We only support suspending on promises that are cached between render attempts. (We do plan to partially support this in the future, at least in certain constrained cases, like during a route transition.)
This includes the case where a component returns an uncached promise, which is effectively what happens if a Client Component is authored using async/await syntax.
This is an easy mistake to make in a Server Components app, because async/await is available in Server Components.
In the current behavior, this can sometimes cause the app to crash with an infinite loop, because React will repeatedly keep trying to render the component, which will result in a fresh promise, which will result in a new render attempt, and so on. We have some strategies we can use to prevent this — during a concurrent render, we can suspend the work loop until the promise resolves. If it's not a concurrent render, we can show a Suspense fallback and try again at concurrent priority.
There's one case where neither of these strategies work, though: during a sync render when there's no parent Suspense boundary. (We refer to this as the "shell" of the app because it exists outside of any loading UI.)
Since we don't have any great options for this scenario, we should at least error gracefully instead of crashing the app.
So this commit adds a detection mechanism for render loops caused by async client components. The way it works is, if an app suspends repeatedly in the shell during a synchronous render, without committing anything in between, we will count the number of attempts and eventually trigger an error once the count exceeds a threshold.
In the future, we will consider ways to make this case a warning instead of a hard error.
See #26801 for more details.