You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, the limit should probable only be changed for the debugging case, and I don't know the code enough to suggest a solution.
In my setup, I hit this limit as soon as a breakpoint hits. I use 15 durable object namespaces. If I reduce the number of loaded namespaces, the problem goes away.
The text was updated successfully, but these errors were encountered:
Hmm, this suggests that the devtools WebSocket connection is being proxied through a worker. Wrangler normally creates a hidden proxy worker around the application itself, but is it also proxying devtools inspector connections? It seems like this shouldn't be needed -- can wrangler connect directly to the inspector port instead?
I am also seeing this behavior persisting after the merged fix. Would be great if team could fix sooner rather than later, I have downgraded wrangler (which depends on workerd) to 3.18.0 as a workaround. Steps to replicate for me are to have a codebase in excess of roughly 10,600 lines (obviously that will vary for you), set a breakpoint, attach debugger, hit breakpoint.
As mentioned in #1563, this still happens for large devtools messages that are passed between workerd instances.
Since these messages get read here:
workerd/src/workerd/api/web-socket.c++
Line 913 in ce1f7c3
They are also limited by the default 1M limit.
As an experiment (main...erkkah:workerd:fix/hanging-debugsession) I increased the limit, which made the problem go away.
However, the limit should probable only be changed for the debugging case, and I don't know the code enough to suggest a solution.
In my setup, I hit this limit as soon as a breakpoint hits. I use 15 durable object namespaces. If I reduce the number of loaded namespaces, the problem goes away.
The text was updated successfully, but these errors were encountered: