Bound every pipeline lock wait: fail the stage on timeout, name the holder, add a no-progress watchdog
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
The issue covers every lock taken in a pipeline stage, so start by finding where stages acquire locks, such as flock calls in the stage scripts, and where the global run deadline is enforced. Add a bounded wait that fails the stage on timeout and prints the holder's PID, command and start time when readable. The done check is a test that holds the lock, runs the stage, and confirms it fails within the bound and names the holder. The no-progress watchdog is a separate part and should be scoped with maintainers first.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem. An unbounded lock wait in a pipeline stage looks like a slow run. It burns the whole run budget, then fails with a generic deadline error that names no cause.
Failure scenario. A stage re-enters a script that takes the same non-reentrant lock its parent holds. It blocks at near-zero CPU with no output until the global deadline, and the log never says who held the lock.
Proposed practice.
- Every lock in a pipeline path uses a bounded wait (for example
flock -w <seconds>). - On timeout, fail that stage at once and print the holder (PID, command, start time) when readable.
- Add a no-progress watchdog: no output and near-zero CPU for a set window aborts the run with a stated reason.
Done when. A test that holds the lock and runs the stage fails within the bounded wait and names the holder. Related: #483, #2166.
- Lenguaje dominante
- Python
- Estrellas
- 2
- Forks
- 1
- Merge medio
- 1 h 29 min
- PR fusionados (30 d)
- 567
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una 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 protocol/perun
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Review pipeline-tooling changes under the copy the pipeline actually runs, not the PR's own copyAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
Todos los issues de protocol/perun
Issues similares
-
area/test type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Clodmony/starship-coop#70 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
punitarani/fli#270 ·
-
🐛 Bug 🔔 Pending processing
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
jumpserver/jumpserver#17980 ·
Los mantenedores suelen responder en 1 día
-
community enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Claiming namespace `prodmetrics`Abiertonamespace
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
EclipseFdn/open-vsx.org#15341 ·
Los mantenedores suelen responder en 1 día