[pull] main from facebook:main#344
Merged
Merged
Conversation
…34906) For debug purposes this is the value that the `React.lazy` resolves to. It also lets us look at that value for descriptions like its name.
) Stacked on #34906. Infer name from stack if it's the generic "lazy" name. It might be wrapped in an abstraction. E.g. `next/dynamic`. Also use the function name as a description of a resolved function value. <img width="310" height="166" alt="Screenshot 2025-10-18 at 10 42 05 AM" src="https://github.com/user-attachments/assets/c63170b9-2b19-4f30-be7a-6429bb3ef3d9" />
…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.
When you use the `createFromFetch` API we assume that the start time of the request is the same time as when you call `createFromFetch` but in principle you could use it with a Promise that starts earlier and just happens to resolve to a `Response`. When you use `createFromReadableStream` that is almost definitely the case. E.g. you might have started it way earlier and you don't call `createFromReadableStream` until you get the headers back (the fetch promise resolves). This adds an option to pass in the start time for debug purposes if you started the request before starting to parse it.
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 free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )