You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scenario: Our goal is to allow our Python customers to debug and run a Python container with F5 using a launch task. Currently, the only way to debug a Python container is to launch the container separately and then remotely attach to an already running Python debugger. With the new feature we are proposing, we need the ability for our launch task to launch the container and the (newest version) Python debugger, then immediately attach the container to the volume mapped debugger successfully.
Issue: @haniamr has been attempting to create this experience, but each time he launches his container with the launch task and tries to start and attach to the Python debugger, the connection is refused, it fails, and exits. Unlike the Node or .NET debugger in VSCode, the Python debugger does not have retry logic implemented when a connection is unable to be established in a given time after a launch. This is a feature gap inhibits the aforementioned scenario and forces users like Hani to attempt to write their own retry logic or find a workaround. Two workarounds that have been found are to sleep for a few seconds which ensures the debugger will be ready to establish a connection or to look for a file that the debugger generates in the container when it's ready. Unfortunately, neither of these are long term solutions.
Proposal: Retry logic should be included as in-box feature within the Python Debugger.
I see. @fiveisprime, this issue has been around since September of last year. With this new scenario that is aiming to enable users of Python (a very popular language) to debug with Docker (also widely used), I need this to be prioritized. Who can I get in contact to reprioritize this feature gap?
Scenario: Our goal is to allow our Python customers to debug and run a Python container with F5 using a launch task. Currently, the only way to debug a Python container is to launch the container separately and then remotely attach to an already running Python debugger. With the new feature we are proposing, we need the ability for our launch task to launch the container and the (newest version) Python debugger, then immediately attach the container to the volume mapped debugger successfully.
Issue: @haniamr has been attempting to create this experience, but each time he launches his container with the launch task and tries to start and attach to the Python debugger, the connection is refused, it fails, and exits. Unlike the Node or .NET debugger in VSCode, the Python debugger does not have retry logic implemented when a connection is unable to be established in a given time after a launch. This is a feature gap inhibits the aforementioned scenario and forces users like Hani to attempt to write their own retry logic or find a workaround. Two workarounds that have been found are to sleep for a few seconds which ensures the debugger will be ready to establish a connection or to look for a file that the debugger generates in the container when it's ready. Unfortunately, neither of these are long term solutions.
Proposal: Retry logic should be included as in-box feature within the Python Debugger.
@fiveisprime
The text was updated successfully, but these errors were encountered: