Detect whether debugger is already running and skip connecting/listen…

[oelhammouchi]

fixes #1296

[oelhammouchi]

@microsoft-github-policy-service agree

[rchiodo]

I'm curious why you put the flag in the environment variables instead of just a global?

[oelhammouchi]

I drew inspiration from the werkzeug code which distinguishes subprocesses spawned in the reloader in this way (it was werkzeug's changes that originally caused the problem). I'm not sure a global will work since it won't be set when the child process spawns, or am I wrong?

[rchiodo]

Okay so this is specifically the case that a subprocess shouldn't connect. I'm wondering if there's a situation that this might break. Like if you wanted to connect to subprocesses too. I believe that's what the subProcess flag is for. Would this change prevent all subProcess connections from working?

Could you instead pass --config-subprocess=false during your initial start of flask? (as described here:

debugpy/README.md

Line 61 in fb6158a

-m debugpy --listen localhost:5678 --pid 12345 --configure-subProcess False

)

[rchiodo]

If that doesn't work, I don't think this is the fix we'd want. It seems like the reload from werkzeug should cause the original process to die before reloading. Maybe we can do that here (wait for the original server to finish if we get an address in use).

[oelhammouchi]

Ok so I'm trying to verify this use case but I can't get it working. I'm using the example app

# playground.py
from flask import Flask
from multiprocessing import Process, Queue
from time import sleep

app = Flask(__name__)


def long_calculation(queue: Queue):
    sleep(5)
    queue.put(5)


@app.route("/")
def get_data():
    queue = Queue()
    p = Process(target=long_calculation, args=(queue,))
    p.start()
    p.join()
    res = queue.get()
    return str(res), 200

which I'm running with the command

python -m debugpy --listen 127.0.0.1:5678 --configure-subProcess False -m flask -A playground run --no-debug

However, if I set a breakpoint in the helper function in VS Code and connect, it blocks at the breakpoint without showing this in the UI, so that the only way to unblock things is to shut down the program.

If I'm doing something wrong here, can you indicate how the flag is supposed to work? It's difficult to test if my fix would break this functionality without knowing how it's supposed to work in the first place 😅

[oelhammouchi]

If it doesn't attach to child processes, I wouldn't expect it to hit a breakpoint inside a function running in such a process, but it does.

On Linux it doesn't seem to work with the latest bits, at least for me (as I commented on the issue as well).

[rchiodo]

Okay I see what you mean about blocking the UI. If I stick a breakpoint in the subprocess code (and subProcess is false), the request never finishes. Without the breakpoint it works fine.

Seems like a separate issue, but yes it doesn't debug a child process if you pass the --configure-subProcess False. Which seems like what you'd want. I'm afraid your change would cause the same thing for all sub processes.

So with your change, can you still hit a breakpoint in the long_calculation?

[rchiodo]

I just tried it and it seems like it works still. It doesn't force subprocess debugging off.

[oelhammouchi]

Yes I can

[int19h]

It still works because subprocesses don't use this code path to connect. Rather, pydevd itself handles subprocesses here, such that the subprocess immediately connects to the debugpy adapter process (which then propagates this new connection to the client).

[rchiodo]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[int19h]

As a general note, there is a similar problem with debugpy API if the subprocess does debugpy.listen explicitly (which happens if it's running the same exact code as the parent). It could be handled in the same way though.