Output from multiple debugger sessions appears in whichever debugger console is active

[hoylemd]

Operating System

macos Monterey

Ruby version

3.22

Project has a bundle

• [ ] Has bundle

Ruby version manager being used

rbenv

Description

I've found that when running multiple debugger processes at the same time, the console output from all processes ends up in whatever debug console window I happen to have open when the output happens

I set up a simple demo repository that can be used to demonstrate the issue fairly easily:

https://github.com/hoylemd/vscode-ruby-console-debug-demo

How to:

• clone that repo
• open up a workspace in the clones repo directory
• install the ruby-lsp extension if it's not already active
• Run the 'hickory(lsp)' debug configuration
• immediately also run the 'dickory(lsp)' debug configuration

You'll see the output from both processes appear in whatever debug console window you have open, they're prefixed with their names so you can tell which is which.

e.g.

The same issue appears in the vscode_rdbg extension, I'll log a similar issue under that and link it here: https://github.com/ruby/vscode-rdbg/issues/318

@st0012 on the Ruby DX slack server had this to say about it (in rdbg), which may be helpful in fixing the issue:

Yeah I think it’s probably because the extension always passes the active debug console to functions that run debuggee processes.

They went on to say it appears to be in vscode-ruby-lsp too:

Ah yes. vscode-ruby-lsp suffers from the same problem: https://github.com/Shopify/vscode-ruby-lsp/blob/main/src/debugger.ts#L17

[vinistock]

Part of the issue is that there's no way to check if there's something already running in a console/terminal. So the choice is between always using the active console or always creating a new one (even when the existing one is not active).

Can you explain in which scenario you'd like to run two debugging sessions at the same time? Is there a real use case for this?

[hoylemd]

Sure, When I'm working on a web app, I have the main web server (rails) and a task runner (sidekiq) running in rails at the same time. Normally they'd be run via foreman as 2 processes. Often I'll be debugging a workflow where a back-end action (rails) triggers a task (sidekiq), and I want to have breakpoints for both.

I think my expectation in this case would be to always create a new console for each debugging session, or at least have the consoled tied to the debugging configuration that they were launched under (the UI seems to imply this is how it works, hence my expectation). Not sure how feasible that is though

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[0llirocks]

Just wanted the check whether this issue is still active. We have the same issue when running multiple processes at the same time e.g. puma, vite, chrome for rails + react development.

All output is written to the active debug console which is unfortunate.

[vinistock]

To fix this, someone has to investigate approaches to improve the experience. Based on the VS Code API docs, it doesn't look like you can have multiple debug consoles (like you can with terminals using createTerminal).

If it's really not possible to have multiple debug consoles, then we need to brainstorm ideas of how we can improve the experience within the limitation of only having one debug console. Can we prefix the logs of each debug server with a name? If that's enough, can we achieve this from the extension side only or does it require changes in the debug gem?

If this is an issue for other programming languages too, should we create an issue in VS Code asking if they plan to support multiple debug consoles? Or what their recommended approach for this would be.

[hoylemd]

Just a bit of clarification - I'm pretty sure you can have more than one debug consoles at the same time, if you run more than one debugging session concurrently, you get a separate tab for each session. Maybe that*'s the bug though, that they appear to be separate consoles, but they're really the same one under the hood? It's a bit of a weird situation

(*I think it's a tab? I don't have mine set up to reproduce this anymore since i went back to old school byebug in-terminal debugging)

[vinistock]

Thanks for the extra context. This could either be a bug in VS Code or our own incorrect usage of the debug console.

Either starting more than one session on the same console shouldn't be allowed (or should automatically do the right thing) or we're not supposed to do that and should prevent the user from doing so.

[hoylemd]

I get the impression that multiple debug sessions of the same type are supposed to work, given the examples shown for compound configurations. But given @st0012 's comments about how the active debug console is always passed into the debugee, I'm leaning more towards it being a bug (or simply an oversight) in VSCode. I'm thinking that maybe the debug console that gets passed in is like an abstracted reference to 'the active debug console'. So when the user switches debugger tabs, that console changes, but as far as the debugee knows it's the same console. Maybe there's a way to dereference that immediately upon launching the debuggee? A new console does seem to spin up and be made active for each debug session, so when it launches the active console will be the right one for that debugee, but it could change any time after that moment.

[vinistock]

Maybe there's a way to dereference that immediately upon launching the debuggee?

This should be easy to test and verify if it fixes the issue. Instead of memoizing the active debug console here we'd need to grab it in a local variable when spawning the server.

[hoylemd]

Sounds like a great excuse to set up for contributing to the extension. If only I had the time...

[vinistock]

Given that we're only implementing the debug adapter interface in the client and considering the fact that VS Code does not have an API to create more debug consoles (unlike terminals), I'm going to assume that this is the intended behaviour.

Please re-open if you discover this is not the case.

[hoylemd]

I'm trying to see if the behaviour is still happening as reported, but I can't even get the debugger to run in my demo repo anymore:

I tried reinstalling the extension, no dice

Could that be related to what you mentioned about the debug adapter being in the client? The launch.json file there is unchanged, and it does seem to match the sample in the docs.

Seems to me that debugging with ruby_lsp is even more broken than before. Perhaps I should open a new issue for this?

[hoylemd]

Also I found this issue in the vscode repo https://github.com/microsoft/vscode/issues/178655

(though credit where it's due, others linked between a few other issues that allowed me to find it easily, I didn't do any intense research to find it :p)

That suggests to me that the issue indeed lies in the debug adapter implementation, specifically this comment

I think my answer for this is just that DAs should try to do a proper DAP implementation that sends OutputEvents over DAP.

Admittedly, I have very little understanding of how the DA works. Is the ruby_lsp DA already sending OutputEvents over DAP or by some other mechanism? If so, it might already be fixed. But I can't be sure because, (as mentioned above) I can't get the ruby_lsp launch configs to work 😅

[vinistock]

I know for a fact that the debug gem communicates with VS Code through the DAP. Whether or not it's using OutputEvents, I'm not sure.

But if it is not using it, then it has to be fixed on the debug gem as the DAP server is implemented there. We only implement the client to connect to it.

[hoylemd]

Alright cool. Maybe that's somehow been fixed then. I'll see if I can get the debugger working again with a fresh workspace to confirm. If it's still putting all the debugging output in the same place, I'll try to find somewhere I can ask about the debug gem. Thanks!