devtools/vscode debugging still fails with Message is too large (>1MB)

[erkkah]

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

auto message = co_await ws.receive();

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.

[penalosa]

cc @irvinebroque @markdembo this seems related to the recent email discussion

[kentonv]

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?

[kyle-pena-nlp]

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.