Uh oh!
There was an error while loading. Please reload this page.
[Flight] Ignore bound-anonymous-fn resources as they're not considered I/O - #34911
Merged
Conversation
react-sizebot
commented
Oct 19, 2025
Comparing: 40c7a7f...d426af1 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
gnoff
approved these changes
Oct 19, 2025
eps1lon
approved these changes
Oct 19, 2025
Uh oh!
There was an error while loading. Please reload this page.
sebmarkbage added a commit
to vercel/next.js
that referenced
this pull request
Oct 19, 2025
#85070) See react/react#34911 This is a weird one but we need some consistent name to ignore these because otherwise they show up as I/O. The simplest is to simply not assign a name to the function being passed. It also can't be auto-assigned by a compiler. Because whatever name the function is given is the name given to the AsyncResource.
github-actionsBot
pushed a commit
that referenced
this pull request
Oct 19, 2025
…d I/O (#34911) When you create a snapshot from an AsyncLocalStorage in Node.js, that creates a new bound AsyncResource which everything runs inside of. https://github.com/nodejs/node/blob/3437e1c4bd529e51d96ea581b6435bbeb77ef524/lib/internal/async_local_storage/async_hooks.js#L61-L67 This resource is itself tracked by our async debug tracking as I/O. We can't really distinguish these in general from other AsyncResources which are I/O. However, by default they're given the name `"bound-anonymous-fn"` if you pass it an anonymous function or in the case of a snapshot, that's built-in: https://github.com/nodejs/node/blob/3437e1c4bd529e51d96ea581b6435bbeb77ef524/lib/async_hooks.js#L262-L263 We can at least assume that these are non-I/O. If you want to ensure that a bound resource is not considered I/O, you can ensure your function isn't assigned a name or give it this explicit name. The other issue here is that, the sequencing here is that we track the callsite of the `.snapshot()` or `.bind()` call as the trigger. So if that was outside of render for example, then it would be considered non-I/O. However, this might miss stuff if you resolve promises inside the `.run()` of the snapshot if the `.run()` call itself was spawned by I/O which should be tracked. Time will tell if those patterns appear. However, in cases like nested renders (e.g. Next.js's "use cache") then restoring it as if it was outside the parent render is what you do want. DiffTrain build for [58bdc0b](58bdc0b)
sebmarkbage pushed a commit
to vercel/next.js
that referenced
this pull request
Oct 20, 2025
[diff react/react@1324e1bb...58bdc0bb](react/react@1324e1b...58bdc0b) <details> <summary>React upstream changes</summary> - react/react#34911 - react/react#34907 - react/react#34906 - react/react#34898 - react/react#34893 - react/react#34892 - react/react#34885 - react/react#34881 - react/react#34894 - react/react#34880 - react/react#34849 - react/react#34900 - react/react#34887 </details>
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
4 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.
When you create a snapshot from an AsyncLocalStorage in Node.js, that creates a new bound AsyncResource which everything runs inside of.
https://github.com/nodejs/node/blob/3437e1c4bd529e51d96ea581b6435bbeb77ef524/lib/internal/async_local_storage/async_hooks.js#L61-L67
This resource is itself tracked by our async debug tracking as I/O. We can't really distinguish these in general from other AsyncResources which are I/O.
However, by default they're given the name
"bound-anonymous-fn"if you pass it an anonymous function or in the case of a snapshot, that's built-in:https://github.com/nodejs/node/blob/3437e1c4bd529e51d96ea581b6435bbeb77ef524/lib/async_hooks.js#L262-L263
We can at least assume that these are non-I/O. If you want to ensure that a bound resource is not considered I/O, you can ensure your function isn't assigned a name or give it this explicit name.
The other issue here is that, the sequencing here is that we track the callsite of the
.snapshot()or.bind()call as the trigger. So if that was outside of render for example, then it would be considered non-I/O. However, this might miss stuff if you resolve promises inside the.run()of the snapshot if the.run()call itself was spawned by I/O which should be tracked. Time will tell if those patterns appear. However, in cases like nested renders (e.g. Next.js's "use cache") then restoring it as if it was outside the parent render is what you do want.