WorkspaceProxy wakes Durable Objects via idFromString(), clearing ctx.id.name for Agents/Lifecycle
维护者通常 1 天内回复
评估
这个 Issue 还没有评估数据。
描述
Describe the bug
When a Durable Object using cloudflare/agents (Lifecycle / Agent / OpenCodeHarness) is paired with @cloudflare/computer's ContainerBackend (or WorkerShellBackend), WorkspaceProxy.#hostStub() and WorkspaceServiceProxy.#hostStub() always resolve the host Durable Object via ns.get(ns.idFromString(id)).
Because a running container outlives Durable Object idle evictions, restarts, and Worker deployments, computerd reconnecting over WorkspaceProxy (/api) is frequently the first caller to wake the Durable Object from a cold start.
In Cloudflare Workers, instantiating a Durable Object via idFromString() does not populate ctx.id.name, so ctx.id.name remains undefined for the entire lifetime of that in-memory Durable Object instance (which stays pinned while the /api WebSocket is open). Any subsequent Lifecycle startup on that instance fails with:
Error: <Class> could not determine its Durable Object name. Address it with idFromName() or getByName().
Expected behavior
WorkspaceRef, WorkspaceProxyProps, and WorkspaceServiceProxyProps should accept an optional name?: string (e.g. this.ctx.id.name) so WorkspaceProxy and WorkspaceServiceProxy resolve the target Durable Object via ns.idFromName(name) (when ns.idFromName(name).toString() === id), preserving ctx.id.name across cold wakes triggered by container callbacks.
A tested patch with workerd unit tests in packages/computer/tests/proxy.test.ts is available at:
https://github.com/4nkitd/computer/commit/efb5ded
Steps to reproduce
- Create a Durable Object class using
withWorkspaceContainer(Base),ContainerBackend, andLifecycle.install(this)(fromagents/lifecycle). - Address the Durable Object via
env.Agent.getByName("main")and start a container command socomputerdconnects back viaWorkspaceProxy. - Redeploy the Worker or let the Durable Object evict while the container remains running so
computerdreconnects viaWorkspaceProxy(ns.get(ns.idFromString(id))) before the next externalgetByName("main")request. - Trigger
lifecycle.start()on the woken Durable Object;ctx.id.nameisundefinedandLifecyclethrowscould not determine its Durable Object name.
Environment
@cloudflare/computer:0.5.1agents:0.28.1wrangler:4.151.0(compatibility_date: 2026-10-15)
- 主要语言
- TypeScript
- 星标
- 9.6k
- 派生
- 558
- 平均合并
- 1 天 19 小时
- 30 天内合并 PR
- 52
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
cloudflare/computer 的其他 Issue
-
dofs: resolving a directory scans its children as the directory grows可能已有人在做 @aron-cf 于 5 天前认领。 未关闭bug
cloudflare/computer#236 · 已指派 1 人 ·
维护者通常 1 天内回复
-
enhancement
难度 4/5 3-5 天 新手友好度 30/100
cloudflare/computer#224 · 5 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
Always run the "next" computerd workflow on push to the `release` branch可能已有人在做 @aron-cf 于 9 天前认领。 未关闭bug
cloudflare/computer#222 · 2 条评论 · 1 个 reaction · 已指派 1 人 ·
维护者通常 1 天内回复
-
Make just-bash and acorn optional peer dependencies, pulled in only by the backend that needs them未关闭enhancement
难度 3/5 1-2 天 新手友好度 45/100
cloudflare/computer#220 · 3 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
Workspace namespaces: more than one Workspace per Durable Object storage可能已有人在做 @aron-cf 于 10 天前认领。 未关闭enhancement
cloudflare/computer#219 · 1 条评论 · 1 个 reaction · 已指派 1 人 ·
维护者通常 1 天内回复
查看 cloudflare/computer 的全部 Issue
相似的 Issue
-
bug priority: P2
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 73/100
mattermost/compass-design#106 ·
维护者通常 1 天内回复
-
clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:other issue-rating: 🦞 diamond lobster P2
难度 2/5 1-3 小时 新手友好度 76/100
openclaw/openclaw#176671 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 66/100
nordcraftengine/nordcraft#1400 ·
维护者通常 1 天内回复