watch: a failed deploy blocks every later deploy on the deployment hold
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 42/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- aws, node.js, typescript
- 领域
- devtools
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- TypeScript
- 星标
- 54
- 派生
- 1
- 平均合并
- 1 小时 45 分钟
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
notationlabs/notation 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
notationlabs/notation#48 ·
-
难度 5/5 一周以上 新手友好度 35/100
notationlabs/notation#34 ·
-
envs as config未关闭
难度 5/5 一周以上 新手友好度 35/100
notationlabs/notation#33 ·
-
难度 3/5 1-2 天 新手友好度 45/100
notationlabs/notation#16 ·
-
难度 4/5 3-5 天 新手友好度 45/100
notationlabs/notation#15 ·
查看 notationlabs/notation 的全部 Issue
相似的 Issue
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256未关闭area: backend documentation priority: low
难度 2/5 1-3 小时 新手友好度 84/100
snapotter-hq/SnapOtter#2919 ·
维护者通常 1 天内回复
-
accepted :+1: bug db/redis
难度 2/5 1-3 小时 新手友好度 76/100
beekeeper-studio/beekeeper-studio#4882 · 1 条评论 ·
维护者通常 1 天内回复
-
ready-for-triage
难度 2/5 1-3 小时 新手友好度 72/100
konflux-ci/konflux-ui#1630 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
ahmedkhaleel2004/gitdiagram#233 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
simkimsia/netlify-axi#19 ·
维护者通常 1 天内回复