Python plugin fails with debugpy 1.8.16 - timeout during adapter connection

[sebor255]

Python plugin fails with debugpy 1.8.16 - timeout during adapter connection

Environment

• Gauge version: 1.6.21 (Commit Hash: 7d3f2cf)
• Gauge plugins: html-report (4.3.3), json-report (0.5.2), python (0.4.11), screenshot (0.3.2)
• VS Code Gauge extension: v0.2.3
• debugpy version: 1.8.16 (broken), 1.8.15 (works)
• Python version: 3.12.11
• OS: Windows

Description

When running Gauge specs with debugpy 1.8.16, the Python plugin consistently fails with a timeout error during debugpy adapter connection. The plugin's start.py calls debugpy.listen() but the adapter connection times out. Downgrading to debugpy 1.8.15 resolves the issue completely.

This appears to be a compatibility issue between Gauge Python plugin and the latest debugpy version.

Steps to Reproduce

1. Install debugpy 1.8.16: pip install debugpy==1.8.16
2. Configure Gauge Python plugin with debugging enabled
3. Run any Gauge spec: gauge run --hide-suggestion --simple-console <spec_file>
4. Observer timeout error

Expected Behavior

The debugger should connect successfully and allow debugging of test execution, as it does in version 1.8.15.

Actual Behavior

Traceback (most recent call last):
  File "<venv>\Lib\site-packages\debugpy\server\api.py", line 235, in listen
    sock, _ = endpoints_listener.accept()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<python>\Lib\socket.py", line 295, in accept
    fd, addr = self._accept()
               ^^^^^^^^^^^^^^
TimeoutError: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\...\AppData\Roaming\gauge\plugins\python\0.4.11\start.py", line 72, in <module>
    main()
  File "C:\Users\...\AppData\Roaming\gauge\plugins\python\0.4.11\start.py", line 29, in main
    start()
  File "C:\Users\...\AppData\Roaming\gauge\plugins\python\0.4.11\start.py", line 52, in start
    debugpy.listen(('127.0.0.1', int(debug_port)))
  File "<venv>\Lib\site-packages\debugpy\public_api.py", line 47, in wrapper
    return wrapped(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "<venv>\Lib\site-packages\debugpy\server\api.py", line 133, in debug
    log.reraise_exception("{0}() failed:", func.__name__, level="info")
  File "<venv>\Lib\site-packages\debugpy\server\api.py", line 131, in debug
    return func(address, settrace_kwargs, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<venv>\Lib\site-packages\debugpy\server\api.py", line 249, in listen
    raise RuntimeError("timed out waiting for adapter to connect")
RuntimeError: timed out waiting for adapter to connect

Workaround

Downgrade to debugpy 1.8.15:

pip install debugpy==1.8.15

Additional Context

The issue is in the Gauge Python plugin's start.py (line 52) which calls debugpy.listen(('127.0.0.1', int(debug_port))). Something changed in debugpy 1.8.16 that breaks the adapter connection flow.

The timeout occurs even with extended timeout values configured in Gauge Python properties. This suggests the issue is not just timing but a breaking change in debugpy's API or connection handling.

Suggested Fix

• Pin debugpy version to <=1.8.15 in plugin requirements, or
• Update plugin's debugpy integration to work with 1.8.16+, or
• Investigate if debugpy's listen() API changed and needs different parameters/setup

[chadlwilson]

Perhaps you can try with 0.5.0, since 0.4.11 is not the latest release - but not much has changed there.

Given they seem to be making changes to this area in debugpy; perhaps you could figure out what they changed, as nothing has changed in this library - and probably they shouldn't be intentionially breaking things in patch releases.

https://github.com/microsoft/debugpy/releases/tag/v1.8.16
microsoft/debugpy#1939 / microsoft/debugpy#1917

To keep your expectations in line, this is very unlikely to be fixed in gauge-python unless it is fixed upstream or someone can submit a PR which is easy enough to review/validate. I dont think any remaining gauge maintainers ever use Windows day-to-day.