Non-stop 'variables' requests after logging with variablesReference

[roblourens]

• Start a node2 debug session with verboseDiagnosticLogging enabled.
• console.log({a: 1})
• Expand the logged object
• See the variables requests logged over and over.

It looks like the console is being refreshed constantly, if you can't repro it I can debug some more.

[roblourens]

Also, after terminating the session, I get another variables request, which fails because Chrome is shut down.

[isidorn]

This is by design of our debug console, namely on every new element we refresh the whole console since the console is implemented using a tree and that is the only way to show a new element in the tree. Unfortunetly for your use case you end up in an endless loop

This should be fixed via #11462
Though we are currently not pushing on that one since in Alex's own words: "debug repl is exposed to the extension host, and before adding another type of editor that is exposed to the extension host, we'd like to first figure out how we can separate it. The biggest problem there is the command service, where the editor dispatches everything through it. i.e. all cursor movement, etc"
So should be done in the future but not yet on the plan.

[roblourens]

This is causing https://github.com/Microsoft/vscode-chrome-debug/issues/364 now - I thought something like this might happen, but I hadn't seen any problem until Chrome 56 was released. After refreshing the page, the debug adapter can't request the properties of objects that were logged earlier.

I can fix this by caching the data in the debug adapter. If I don't, and just respond with an empty request or error, logged objects from before the refresh will disappear from the console, which is not helpful. But can we cache this data on vscode's side so other debug adapters can benefit? It's also leading to lots of unnecessary traffic on the debug adapter socket, and I wonder if it would cause problems in a very long debug session.

[isidorn]

@roblourens now I am caching children for all expressions. Hopefully this does not break anything, we can wait and see. Previously I was not doing any caching because the tree would cache for me, but as you nicely point out here in REPL we are doing a lot of refreshes so we should also cache on our side.

I invalidate the cache whenever an expression container changes reference so I belive that should catch all cases.

@joaomoreno I tried using your nice memoize functionality but could not figure out how to drop the cache. Is that possible?

[isidorn]

@roblourens please verify