[Flight] Serialize rate limited objects in console logs as marker an increase limit #30294
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
This marker can then be emitted as a getter. When this object gets accessed we use a special error to let the user know what is going on.
These limits are per message. Unfortunately we don't really do much deduping in these logs so with cyclic objects it ends up maximizing the limit and then siblings aren't logged.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
gnoff
approved these changes
Jul 9, 2024
github-actions bot
pushed a commit
that referenced
this pull request
Jul 10, 2024
…increase limit (#30294) This marker can then be emitted as a getter. When this object gets accessed we use a special error to let the user know what is going on. <img width="1350" alt="Screenshot 2024-07-08 at 10 13 46 PM" src="https://github.com/facebook/react/assets/63648/e3eb698f-e02d-4394-a051-ba9ac3236480"> When you click the `...`: <img width="1357" alt="Screenshot 2024-07-08 at 10 13 56 PM" src="https://github.com/facebook/react/assets/63648/4b8ce1cf-d762-49a4-97b9-aeeb1aa8722c"> I also increased the object limit in console logs. It was arbitrarily set very low before. These limits are per message. So if you have a loop of many logs it can quickly add up a lot of strain on the server memory and the client. This is trying to find some tradeoff. Unfortunately we don't really do much deduping in these logs so with cyclic objects it ends up maximizing the limit and then siblings aren't logged. Ideally we should be able to lazy load them but that requires a lot of plumbing to wire up so if we can avoid it we should try to. If we want to that though one idea is to use the getter to do a sync XHR to load more data but the server needs to retain the objects in memory for an unknown amount of time. The client could maybe send a signal to retain them until a weakref clean up but even then it kind of needs a heartbeat to let the server know the client is still alive. That's a lot of complexity. There's probably more we can do to optimize deduping and other parts of the protocol to make it possible to have even higher limits. DiffTrain build for commit 14fdd0e.
github-actions bot
pushed a commit
that referenced
this pull request
Jul 10, 2024
…increase limit (#30294) This marker can then be emitted as a getter. When this object gets accessed we use a special error to let the user know what is going on. <img width="1350" alt="Screenshot 2024-07-08 at 10 13 46 PM" src="https://github.com/facebook/react/assets/63648/e3eb698f-e02d-4394-a051-ba9ac3236480"> When you click the `...`: <img width="1357" alt="Screenshot 2024-07-08 at 10 13 56 PM" src="https://github.com/facebook/react/assets/63648/4b8ce1cf-d762-49a4-97b9-aeeb1aa8722c"> I also increased the object limit in console logs. It was arbitrarily set very low before. These limits are per message. So if you have a loop of many logs it can quickly add up a lot of strain on the server memory and the client. This is trying to find some tradeoff. Unfortunately we don't really do much deduping in these logs so with cyclic objects it ends up maximizing the limit and then siblings aren't logged. Ideally we should be able to lazy load them but that requires a lot of plumbing to wire up so if we can avoid it we should try to. If we want to that though one idea is to use the getter to do a sync XHR to load more data but the server needs to retain the objects in memory for an unknown amount of time. The client could maybe send a signal to retain them until a weakref clean up but even then it kind of needs a heartbeat to let the server know the client is still alive. That's a lot of complexity. There's probably more we can do to optimize deduping and other parts of the protocol to make it possible to have even higher limits. DiffTrain build for [14fdd0e](14fdd0e)
This was referenced Jul 25, 2024
sebmarkbage
added a commit
that referenced
this pull request
Aug 30, 2024
#30847) To recap. This only affects DEV and RSC. It patches console on the server in DEV (similar to how React DevTools already does and what we did for the double logging). Then replays those logs with a `[Server]` badge on the client so you don't need a server terminal open. This has been on for over 6 months now in our experimental channel and we've had a lot of coverage in Next.js due to various experimental flags like taint and ppr. It's non-invasive in that even if something throws we just serialize that as an unknown value. The main feedback we've gotten was: - The serialization depth wasn't deep enough which I addressed in #30294 and haven't really had any issues since. This could still be an issue or the inverse that you serialize too many logs that are also too deep. This is not so much an issue with intentional logging and things like accidental errors don't typically have unbounded arguments (e.g. React errors are always string arguments). The ideal would be some way to retain objects and then load them on-demand but that needs more plumbing. Which can be later. - The other was that double logging on the server is annoying if the same terminal does both the RSC render and SSR render which was addressed in #30207. It is now off by default in node/edge-builds of the client, on by default in browser builds. With the `replayConsole` option to either opt-in or out. We've reached a good spot now I think. These are better with `enableOwnerStacks` but that's a separate track and not needed. The only thing to document here, other than maybe that we're doing it, is the `replayConsole` option but that's part of the RSC renderers that themselves are not documented so nowhere to document it.
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.
This marker can then be emitted as a getter. When this object gets accessed we use a special error to let the user know what is going on.
When you click the
...:I also increased the object limit in console logs. It was arbitrarily set very low before.
These limits are per message. So if you have a loop of many logs it can quickly add up a lot of strain on the server memory and the client. This is trying to find some tradeoff. Unfortunately we don't really do much deduping in these logs so with cyclic objects it ends up maximizing the limit and then siblings aren't logged.
Ideally we should be able to lazy load them but that requires a lot of plumbing to wire up so if we can avoid it we should try to. If we want to that though one idea is to use the getter to do a sync XHR to load more data but the server needs to retain the objects in memory for an unknown amount of time. The client could maybe send a signal to retain them until a weakref clean up but even then it kind of needs a heartbeat to let the server know the client is still alive. That's a lot of complexity. There's probably more we can do to optimize deduping and other parts of the protocol to make it possible to have even higher limits.