watch: a failed deploy blocks every later deploy on the deployment hold
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 42/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- aws, node.js, typescript
- Domaine
- devtools
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- TypeScript
- Étoiles
- 54
- Forks
- 1
- Merge moyen
- 1 h 45 min
- PR mergées (30 j)
- 1
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de notationlabs/notation
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
notationlabs/notation#48 ·
-
state provider configOuverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
notationlabs/notation#34 ·
-
envs as configOuverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
notationlabs/notation#33 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
notationlabs/notation#16 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
notationlabs/notation#15 ·
Toutes les issues de notationlabs/notation
Issues similaires
-
engine-rs P3 review-deferral wasm
Difficulté 2/5 1-3 heures Accessibilité débutants 77/100
maniator/verticopolis#1154 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
telerik/kendo-react#3861 ·
Les mainteneurs répondent en général sous 1 jour
-
[bug]: use-mobile.ts uses pixel logic, causing UI state de-sync with Tailwind CSS rem breakpointsOuvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
task
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100