The "restart" setting in attach+listen mode works, but the UI displays wrong after the first restart.

[coredumperror]

Type: Bug

Behaviour

When you use "restart": true in your launch config that runs as a listener, the Debug Toolbar doesn't appear while the server is waiting for a new connection after a restart, making it impossible to tell that it's running, and impossible to stop.

Steps to reproduce:

When you set your launch.json config to the following:

    "request": "attach",
    "restart": true,
    "listen": {
        "port": 6789
    },

VS Code will run the debugger in listen mode, waiting for a client to connect to it via debugpy.connect(). When you first start the debugger with this config, it immediately displays the debug toolbar, and also shows a bar flowing across the Run and Debug panel, indicating that it's waiting for a connection.

Once a client has connected, the debugger works as normal. However, when the client disconnects, the debugger APPEARS to quit, as the toolbar disappears, the "waiting" animation does not come back, and the Launch dropdown re-appears. The debugger is actually still running, waiting for a new connection, but with the Toolbar gone, it's impossible to make it stop.

If you press the Start Debugging button again, you'll get a dialog claiming that the debugger is already running, and asking if you want to start another instance. If you do that, you'll then finally see the still-running instance in the Call Stack listing, alongside the new one. You can then close both if you quickly hit the Disconnect button on both (it appears on them when you hover over them), but if you wait too long and one of them closes, the other disappears form the list, too, while still running.

Diagnostic data

launch.json configuration

This is the contents of the "launch" key in my .vscode-workspace file, as my code shop does not use the .vscode folder, so I can't use an actual launch.json. I doubt that's relevant, but just in case...

"launch": {
    // Debugger configuration for Python
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug TESTS",
            "type": "debugpy",
            "request": "attach",
            "restart": true,
            "listen": {
                "port": 6789
            },
            "justMyCode": false,
            "django": true,
            "jinja": true,
            "pathMappings": [
                // Map the root of the wagtail-multitenant repo to the /multitenant directory in the container.
                {
                    "localRoot": "${workspaceFolder:wagtail-multitenant}",
                    "remoteRoot": "/multitenant"
                },
                // Map the host venv into the /ve folder. This must go last to ensure that mappings to
                // our library repos aren't overridden.
                {
                    "localRoot": "${workspaceFolder:wagtail-multitenant}/.venv",
                    "remoteRoot": "/ve"
                },
            ],
            "variablePresentation": {
                // Valid settings are "class", "protected", "function", and "special".
                // Valid values are "inline", "group", and "hide".
                // To activate changes, you must stop and start the debugger. Restart does not work.
                // "all" sets the default for everything. Any of the following that are unset will be inlined,
                // which is how instance attributes are always displayed.
                "all": "inline",
                // Group attributes/globals that are classes into a "class variables" group.
                "class": "group",
                // Group attributes prefixed with a single underscore into a "protected variables" group.
                "protected": "group",
                // Hide the "function variables" group, which contains all of an object's functions.
                "function": "hide",
                // Hide the "special variables" group, which contains all of an object's dunders (e.g. __class__).
                "special": "hide",
            },
            "showReturnValue": false,
        },
    ]
},

There are a few other congigs in there, too. Let me know if you want the entire list, though I can't see that being relevant.

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

None

Output for Python Debugger in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python Debugger)

This is what the Python Debugger output looks like after starting the server fresh, then connecting and disconnecting, and then doing that again.

2025-04-30 18:46:05.699 [info] Resolving attach configuration with substituted variables
2025-04-30 18:46:05.699 [info] Using workspaceFolder found for the program:  /Users/rrollins/dev/wagtail-multitenant
2025-04-30 18:46:05.702 [info] DAP Server launched with command: /Users/rrollins/dev/wagtail-multitenant/.venv/bin/python /Users/rrollins/.vscode/extensions/ms-python.debugpy-2025.6.0-darwin-arm64/bundled/libs/debugpy/adapter
2025-04-30 18:46:05.883 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:05.883 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:13.368 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:13.679 [info] DAP Server launched with command: /Users/rrollins/dev/wagtail-multitenant/.venv/bin/python /Users/rrollins/.vscode/extensions/ms-python.debugpy-2025.6.0-darwin-arm64/bundled/libs/debugpy/adapter
2025-04-30 18:46:13.834 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:13.835 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:21.822 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:22.134 [info] DAP Server launched with command: /Users/rrollins/dev/wagtail-multitenant/.venv/bin/python /Users/rrollins/.vscode/extensions/ms-python.debugpy-2025.6.0-darwin-arm64/bundled/libs/debugpy/adapter
2025-04-30 18:46:22.292 [info] Received 'debugpySockets' event from debugpy.
2025-04-30 18:46:22.292 [info] Received 'debugpySockets' event from debugpy.

Extension version: 2025.6.0
VS Code version: Code 1.98.2 (ddc367ed5c8936efe395cffeec279b04ffd7db78, 2025-03-12T13:32:45.399Z)
OS version: Darwin arm64 24.4.0
Modes:

• Python version (& distribution if applicable, e.g. Anaconda): 3.11.11
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): VirtualEnvironment

System Info

Item	Value
CPUs	Apple M2 Max (12 x 2400)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	2, 2, 2
Memory (System)	32.00GB (0.14GB free)
Process Argv	--crash-reporter-id b81eb320-abb0-46fb-961c-411594599894
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dwnewjupytercf:31046870
pythonrstrctxt:31112756
nativeloc2:31192216
5fd0e150:31155592
dwcopilot:31170013
6074i472:31201624
dwoutputs:31242946
customenabled:31248079
hdaa2157:31222309
copilot_t_ci:31222730
968h8231:31277804
pythoneinst12:31285622
bgtreat:31268568
4gafe986:31271826
5b33h341:31253271
31787653:31262186
3e8i5726:31271747
996jf627:31283433
usemplatestapi:31297334
7bj51361:31289155
aj496949:31278748
aj953862:31281341
generatesymbolt:31295002
convertfstringf:31295003
gendocf:31295004

[coredumperror]

OH! I just now noticed that this effect does not happen if you call debugpy.connect() from within a Django request on a server running in gunicorn. Instead of the UI visually switching back to "I'm not actually running the server" mode, you get this after a request finishes:

This is what it looks like while the server is still running, but it was recently connected to by a manage.py command calling ``debugpy.connect()`, instead:

I'm also experimenting with calling pydevd.stoptrace() at the end of my requests, to explicitly disconnect from the debug server. If I don't do that, the breakpoints in my manage.py scripts don't get hit (even though the client seems to successfully connect). I have to restart the server to make them work again (or call pydevd.stoptrace() in the django code).