Add support to retry attaching within a specific timeout

[bwateratmsft]

Summary

• Basically the debugger is launched before the preLaunch script completes. Hence the debugger fails (as the process has not started and socketserver is not listening).
• Suggestion: Retry attaching to the socket with a default timeout period.
• Note; This is not a bug, but a work around for the preLaunchScripts returning even before the script has actually completed (i.e. work around for docker extension issues).

Environment data

• VS Code version: 1.38
• Extension version: 2019.9.34911
• OS and version: Windows 10, 1903
• Python version: 3.7.2

Steps to reproduce:

1. Create a Python file, e.g. myApp.py within a workspace folder
2. Create a task in tasks.json to launch that file in PTVSD in a Docker container (see below for full tasks.json), e.g. with:
   docker run -dt -v C:\Users\brandonw\.vscode\extensions\ms-python.python-2019.9.34911\pythonFiles:/pydbg -v ${workspaceFolder}:/app -w /app -p 5678:5678 --entrypoint python python:alpine /pydbg/ptvsd_launcher.py --default --host 0.0.0.0 --port 5678 --wait myApp.py
3. Set that task as the preLaunchTask for a Python remote attach launch config (see below for full launch.json)
4. F5

Expected behaviour

Attach works if preLaunchTask is used to start a waiting debug server with ptvsd

Actual behaviour

Attach does not work. No error is shown, it appears like debugging starts and immediately stops. If you comment out the preLaunchTask in launch.json, and then manually run the task with Ctrl + Shift + P > Run Task, it will start the container. If you then F5 it attaches successfully. I've also tried putting a dummy task containing a 2-second sleep inbetween, and this also works. So it seems to just be a race condition.

Logs

Nothing is output in Python output window, nor in Developer Tools console window.

Workspace

.vscode/launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Remote Attach",
            "type": "python",
            "request": "attach",
            "port": 5678,
            "host": "localhost",
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "."
                }
            ],
            "preLaunchTask": "Docker start",
            "postDebugTask": "Docker remove"
        }
    ]
}

.vscode/tasks.json (note, you'll need to change the C:\users\brandonw...\pythonFiles:/pydbg path):

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Docker start",
            "type": "shell",
            "command": "docker run -dt -v C:\\Users\\brandonw\\.vscode\\extensions\\ms-python.python-2019.9.34911\\pythonFiles:/pydbg -v ${workspaceFolder}:/app -w /app -p 5678:5678 --name myPythonApp --entrypoint python python:alpine /pydbg/ptvsd_launcher.py --default --host 0.0.0.0 --port 5678 --wait myApp.py",
            "problemMatcher": []
        },
        {
            "label": "Docker remove",
            "type": "shell",
            "command": "docker rm -f myPythonApp"
        }
    ]
}

myApp.py:

print("Hello world!")

print("Farewell!")

[bwateratmsft]

Blocks microsoft/vscode-docker#1255

[DonJayamanne]

Isn't the problem the fact that the preLaunch task returns even before the script has completed. I.e. it's not really an issue with the python extension. However an issue with the preLaunch script.

preLaunch functionality isn't something that's provided by the extension. The extension is doing what it's meant to do. It starts the debugger when VSCode yes it when it's time to do so.

I.e. the race condition is VSCode specific or due to the preLaunch retuning too early

[bwateratmsft]

@DonJayamanne VSCode does actually wait until docker run has finished, but I don't think that docker run waits for python to get up, running, and ready in the container before returning.

[bwateratmsft]

Since it's expected that the entrypoint is a long-running application, the -d option (detached) would mean it doesn't wait for the application to return. We also can't do -i (interactive) as then the task would never return.

[DonJayamanne]

but I don't think that docker run waits for python to get up, running, and ready in the container before returning.

Not sure how this is a bug in the extension. We aren't in control of the preLaunch task or any of that orchestration!

[DonJayamanne]

Same problem could happen with other debuggers.
Either you'd need to find a way to synchronize the two, or find an alternative. (E.g use custom tasks in vscode), or a custom debugger when you manually start docker and that start the debugger using the VSCode API).

[bwateratmsft]

It's not a bug, but it's a shortcoming that can't be addressed by Docker itself or by the Docker VSCode extension (they have no idea what constitutes 'the debugger listener is ready' or how to detect it).

For comparison, the Node.js debugger has a timeout parameter that can help in this sort of scenario: https://github.com/microsoft/vscode-node-debug2/blob/965054f347a8f4ea4a690f82083e9ad8f708633e/package.json#L301