🤖 fix: deleting a Daytona workspace after an account switch leaves its sandbox in the old account
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
Start with src/node/services/daytona/daytonaSandboxes.ts:321 and the review thread linked from the issue, then trace where the workspace’s daytona config is created and used during archive or removal. Check how the current account and 404 responses are handled. Done means the stored API URL and target distinguish accounts, and deletion handles mismatches as described for normal and forced removal.
由索引模型根据 Issue 内容生成。
描述
Follow-up from the Codex review of #7100 (thread: https://github.com/coder/xum/pull/7100#discussion_r4353498597, src/node/services/daytona/daytonaSandboxes.ts:321).
Problem
A Daytona workspace does not record which Daytona account (API URL, key, target) created its sandbox. If the user switches Settings > Runtimes > Daytona from account A to account B and then archives or removes a workspace created under A, Xum asks account B for the sandbox. B answers 404, so the sandbox counts as missing, the delete is treated as done, and the workspace record goes away. The account-A sandbox stays behind: auto-stop (30 min) stops it, but auto-delete is off, so it keeps its disk until someone deletes it in the Daytona dashboard.
Proposed fix
Store an account fingerprint (API URL plus target, never the key) in the workspace's daytona config at create. On archive or remove, if the current account does not match, do not treat a 404 as a deleted sandbox: refuse with a message that names the original API URL/target and asks the user to switch back, or (forced removal) remove the workspace and warn that the sandbox was left in the other account.
Why it is deferred
#7100 runs its review loop under a P0/P1-only rule; P2 findings get a tracked follow-up.
- 主要语言
- TypeScript
- 星标
- 2.1k
- 派生
- 140
- 平均合并
- 3 小时 23 分钟
- 30 天内合并 PR
- 953
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
coder/xum 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
相似的 Issue
-
category::task code priority::normal
难度 2/5 1-3 小时 新手友好度 78/100
e0ipso/strikethroo#145 ·
维护者通常 1 天内回复
-
难度 1/5 1-3 小时 新手友好度 85/100
cocos/cocos-docs#3333 ·
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
RevenueCat/react-native-purchases#2079 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
RevenueCat/purchases-hybrid-common#2039 ·
维护者通常 1 天内回复
-
agent-reported area/react bug
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复