[Flight] Ignore bound-anonymous-fn resources as they're not considered I/O #34911
+21
−10
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.