watch: a failed deploy blocks every later deploy on the deployment hold
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- aws, node.js, typescript
- Área
- devtools
Línea de trabajo
Start with packages/reconciler/src/durable/deployment-hold.ts and trace how watch creates execution IDs for deploys. Compare the hold behavior on failure with the watch rebuild flow; the issue lists resuming the failed execution or clearing its hold as possible directions. Done means a failed deploy no longer leaves later deploys in the same watch session hanging.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
After one deploy fails during notation watch, every later deploy in that session hangs forever on reconciler.hold.waiting.
withDeploymentHold (packages/reconciler/src/durable/deployment-hold.ts) deliberately keeps the hold when an execution fails, so the same execution can be resumed with --execution-id. But watch starts each deploy with a new randomUUID() execution ID and never resumes the failed one. So the next deploy waits for a holder that will never finish, and the only way out is to clear the hold manually.
Repro
- Run
notation watch infra/api.tswith invalid AWS credentials, so the first deploy fails withInvalidClientTokenId. - Edit a runtime file to trigger a rebuild.
- The second deploy logs
reconciler.hold.waitingwithholderExecutionIdset to the first execution, then hangs.
This predates the move to child-process deploys (7735a67), since watch has always used a new execution ID per deploy.
Possible directions
- Have watch resume the failed execution ID on the next rebuild, rather than starting a new one.
- Or have watch clear its own failed execution's hold (it knows the holder is dead) before starting the next deploy.
- Lenguaje dominante
- TypeScript
- Estrellas
- 54
- Forks
- 1
- Merge medio
- 1 h 45 min
- PR fusionados (30 d)
- 1
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 notationlabs/notation
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
notationlabs/notation#48 ·
-
state provider configAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
notationlabs/notation#34 ·
-
envs as configAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
notationlabs/notation#33 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
notationlabs/notation#16 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
notationlabs/notation#15 ·
Todos los issues de notationlabs/notation
Issues similares
-
ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
xavxyz/bei-shan-lin-shui#57 ·
Los mantenedores suelen responder en 1 día
-
[BUG] rag: sentence content can cross the reported sentence boundariesPosiblemente ocupada @LJK-ikun la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
README: the Resource URI Schemas example's file://documents/* pattern only matches that literal URIAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
platformatic/mcp#361 ·
Los mantenedores suelen responder en 1 día
-
最近文档这个弹窗，左右宽度没有最小宽度限制Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
siyuan-note/siyuan#20799 · 7 comentarios ·
Los mantenedores suelen responder en 1 día