watch: a rebuild queued during a failed deploy is never deployed
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 78/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- node.js, typescript
Piste de recherche
Commencez dans packages/cli/src/watch.ts et suivez la façon dont triggerDeploy gère les chemins de réussite et d’échec de la promesse. Reproduisez l’échec en enregistrant une modification pendant un déploiement en cours, puis assurez-vous que le déploiement mis en file d’attente s’exécute après l’un ou l’autre résultat ; vérifiez qu’il n’est pas bloqué par le blocage du déploiement décrit dans #47.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Problem
In packages/cli/src/watch.ts, if a rebuild happens while a deploy is running, triggerDeploy sets deployQueued = true. The .then handler starts the queued deploy, but the .catch handler only resets isDeploying and never checks deployQueued.
So if the running deploy fails, a change saved during it is silently left undeployed until the next file change. That's often exactly the fix for the failure.
Repro
- In
notation watch, start a deploy that will fail. - While it's running, save a change.
- The failed deploy finishes, and the saved change is not deployed until another edit.
Fix
Drain the queue in both paths, e.g. move the deployQueued check into a .finally, or call the same "done" function from .then and .catch.
Note that while #47 is open, the queued deploy would then hang on the deployment hold, so the two are worth fixing together.
- 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é 4/5 3-5 jours Accessibilité débutants 42/100
notationlabs/notation#47 ·
-
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
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
jessepollak/home#2223 ·
Les mainteneurs répondent en général sous 1 jour
-
grep fixture corpus test follows the corpus's loop symlink under the receipt runner (fails on main)Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
code-yeongyu/senpi#3756 ·
Les mainteneurs répondent en général sous 1 jour
-
org:external package:deepagents priority:triage topic:memory topic:middleware type:bug
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
langchain-ai/deepagents#7059 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
osmlab/name-suggestion-index#12992 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
hemilabs/ui-monorepo#2506 ·
Les mainteneurs répondent en général sous 1 jour