Python plugin fails with debugpy 1.8.16 - timeout during adapter connection
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- testing-qa
Línea de trabajo
The reported failure points to the Python plugin’s start.py, where debugpy.listen() is called, and compares debugpy 1.8.16 with 1.8.15. Read that call and check the plugin’s debugpy dependency requirements, then reproduce with both versions using the listed Gauge command. Done means debugging connects successfully with debugpy 1.8.16 or the supported version constraint is clear.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Install debugpy 1.8.16:
pip install debugpy==1.8.16 - Configure Gauge Python plugin with debugging enabled
- Run any Gauge spec:
gauge run --hide-suggestion --simple-console <spec_file> - 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
- Lenguaje dominante
- Python
- Estrellas
- 96
- Forks
- 38
- Merge medio
- 1 h 18 min
- PR fusionados (30 d)
- 2
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de getgauge/gauge-python
-
GAUGE_PYTHON_COMMAND does not support relative paths (e.g. .venv/bin/python)Posiblemente ocupada @JakubStyczen la tomó hace 40 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
getgauge/gauge-python#485 ·
-
help wanted
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
getgauge/gauge-python#324 · 4 comentarios ·
-
help wanted
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
getgauge/gauge-python#265 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
getgauge/gauge-python#245 ·
-
help wanted triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 35/100
getgauge/gauge-python#123 · 1 comentario ·
Todos los issues de getgauge/gauge-python
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
521xueweihan/HelloGitHub#4115 ·
-
get_lldp_neighbors_detail: query asks for 'max-address' (typo for 'mac-address'), so remote_chassis_id is always emptyPosiblemente ocupada @Jah-yee la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
lesson-submission pending-review
Dificultad 1/5 Menos de una hora Aptitud para principiantes 74/100
Ikalus1988/MisakaNet#3899 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
aws-samples/sample-per-model-bedrock#549 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100