Change:
* When true, the debug viewlet will not be automatically revealed for this session. */ suppressDebugView?: boolean; <ins> /** * Signals to the editor that the debug session was started from a test run * request. This is used to link the lifecycle of the debug session and * test run in UI actions. */ testRun?: TestRun; </ins> } /**

Discussion:
Currently, debug sessions and test runs live in two different worlds. This leads to some confusion, because stopping or restarting a debug session using the debug toolbar doesn't stop or restart the test run. Several extension authors have raised this as a pain point. I propose a simple API that would allow the editor to correlate the two: Then it can be passed in
This is now implemented behind the usual proposed shenanigans. Let me know how it works or if folks think anything is missing. This is a simple API so I think we could finalize it next iteration. I think you mentioned this before, +
We could technically make this work without API in some cases by using AsyncLocalStorage to associate sessions started from calls to the runHandlers. But I think we still want API as that is a rather exotic feature that can be defeated though various means.
Gave this a try on the python extension and seems to be fixing the problem we were seeing about not getting the test_ids. I am still seeing the "restart" button in the debug panel leading to the debug session ending, which in the python extension signals to end the run instance. This means that using the refresh button results in the UI not being updated for test success or failures after since the run instance was ended. Should I change my code to not have the run instance end there? How should the extensions know when debug was done vs restarted in terms of ending the test run object? <img width="1727" alt="Screenshot 2024-06-07 at 1 21 11 PM" src=""
In the current implementation, hitting the restart button won't touch the debug session at all but will instead cancel the test run, wait for the run to complete, and then immediately start a new run with the same parameters: You should be able to keep updating states and such until you call
In Dart, we were already handling debug session ends and calling on the test run (whether it was created by VS Code, or by us). We don't seem to have any bugs with stopping debug sessions that are test runs. However, restart doesn't work great - because it seems to end the test run, then start a new debug session that is not tied to a test run (so you don't get the results recorded).

It's not clear to me if your fix here will solve that, but I wonder if there are going to have issues with test runs where VS Code doesn't have all of the related data. We discussed this before in about "Test: Rerun Last Run" not working because of this. If we let VS Code handle restarting test runs by just calling , I think any context that we weren't able to capture in the won't come back to us, and we'll start a test run with some parameters missing.
As I debug it I am still seeing be called when I click "restart". Here is a link to where that is in the extension: If that sounds wrong I can also send over my branch since I might have set it up incorrectly. Thanks
Yep, please send your branch, thanks!
here it is:
Thanks, fixed
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
the selfhost test provider in VS Code a test, and stop on a breakpoint somewhere the "restart" action in the debug toolbar that the test run is cancelled and a new test run is started as debugging is restarted.
I'm not sure if you wanted me to verify anything, but I still don't completely understand the functionality here - see my notes above at
This doesn't affect how debug sessions stop at the moment, only how they restart. When a restart happens, the old test run request is cancelled, and once it ends a new test run request comes in with an identical profile and set of tests as was initially used to start the first run. This should fix the issue of the second, 'untracked' debug session. It sounds like profiles are the right mechanic for your use case. I made some improvements to the case of "if they should only apply to specific files or folders" that you mentioned in your original comment a couple years ago. I you would like some UX improvements to make them more viable I would be happy to discuss
Yep, understood.

But in the case where a test run is created by us (so we can record test results) but doesn't contain all of the information to run a specific set of tests: Then won't Restart now end up running the entire set of tests, rather than just restarting the debug session as it did before (which might record results against the original run, but at least ran the correct set of tests)? I'm assuming if I never set then I won't be affected (we'll continue with the same behaviour), and I could look at providing this in the future if I can move over to profiles or something? Do you have any links to issues about the profile changes so I can see if they handle the cases I had issues with?
Yea -- just like the "rerun" actions would (which as you previously mentioned aren't good in your current setup.) Yep that's right Just a which captures most things, but not everything. Notably I think: the fix for the tagged ones I mentioned before not sure if applicable, but if profiles across kinds have the same name then they'll be kept in sync when the default changes allows getting and setting the default profiles, so you can programmatically query and change them.
Hi, sorry for the late reply. I tested the new api today, I can still hit when restart the debug session, is this as expected? We use to do clean up jobs.
When restarting when a test run is provided, the test run is cancelled. Usually this will result in the extension stopping the debug session which will then trigger