rpc: stub leak tracker under-counts because capnweb disposes the shared server target once per session

[rajpreetcodes]

Describe the bug

The debug stub tracker in @cloudflare/computer-rpc (packages/rpc/src/debug.ts) pairs one trackStub per constructed server object with one untrackStub per [Symbol.dispose] call, floored at zero (debug.ts:39-51). But the documented serving pattern mounts the same RpcTarget on every WebSocket connection (packages/rpc/src/server.ts:345-350 acceptWebSocketSession; computerd and the package's own tests both do this), and capnweb disposes the session's main export on every session teardown (capnweb dist/index.js:2444-2446 session abort disposes export hooks; :1125-1133 disposeRpcTarget calls target[Symbol.dispose]()).

Result: a shared target constructed once but serving N sessions gets untracked N times. The zero floor then silently absorbs the decrements that belong to other live instances of the same class, so the snapshot reports zero while objects are provably alive. The advertised use of this surface is exactly leak detection (package README, GET /__computerd/stubs in packages/computerd/src/cli/computerd.ts:236, and the soak scripts): any reconnect during a soak run under-counts and can mask a real leak, the exact failure mode the tool exists to catch.

Secondary hazard: [Symbol.dispose] fires per-session on an object that keeps serving later sessions (verified: the target successfully served an RPC after its counter had already dropped). Any real cleanup wired into these dispose hooks later would fire prematurely.

Expected behavior

The per-class live count reflects constructed-and-not-yet-final-disposed server objects. Closing a session against a shared target does not decrement the count for other live instances; the snapshot for two live SyncRPCServer objects reports 2.

Steps to reproduce

Test inside packages/rpc (run npm test --workspace @cloudflare/computer-rpc -- <file>):

1. Enable tracking; create two targets via createSyncServer (rpcA, rpcB).
2. Mount rpcA on a WebSocket server (acceptWebSocketSession pattern); open and cleanly close two client sessions against it; make an RPC call on session 2 to prove rpcA still serves.
3. Read the snapshot.

Actual output:

[repro] live SyncRPCServer objects: 2 (rpcA still serving, rpcB in scope)
[repro] counter after 1st session close: 1
[repro] counter after 2nd session close: 0
[repro] full snapshot: {}
AssertionError: expected +0 to be 2

Proposed fix

Make tracking identity-based instead of count-based: keep a module-level set of currently-tracked targets in debug.ts; trackStub increments the class counter only when the target is newly added, untrackStub decrements only when the delete actually removed it, so per-session double-dispose becomes a no-op. Contained to debug.ts, preserves the "per-class live count" semantics, no change to the shared-target mounting pattern. A comment on acceptWebSocketSession noting that capnweb disposes the main export per session would keep future dispose-hook cleanup from being wired to a shared object.

Environment

• cloudflare/computer at 76d9e75 (current main), local checkout
• npm test --workspace @cloudflare/computer-rpc baseline: 62/62 pass
• Node v22.18.0, npm 11.8.0, Windows 11 (platform-independent)

[rajpreetcodes]

Wrong thread, I think: the timezone report is #57, this one is about the RPC stub tracker. On your question though, storing UTC is not the problem. isomorphic-git already stores the epoch plus the author's offset, and commits created inside workerd carry offset 0 and print fine. The bug in #57 is rendering only. formatGitTimestamp prints the UTC wall clock and then appends the author's +0530, so the printed instant is off by the offset for any cloned repo.

[blackwellmiranda8]

📌💡🧪 测试覆盖到关键路径了吗

[harrisonmichael809]

✨ 向量库换一家迁移成本高吗

[3x3xX3N0N]

Confirmed at 76d9e75, with a patch and failing-first tests if useful. Your analysis holds exactly as written — identity, not call count, is the right fix.

What I verified. debug.ts:39-51 pairs one increment per trackStub with one decrement per untrackStub, floored at zero. With one shared target mounted across sessions and capnweb disposing the main export per teardown, the repeat decrements are absorbed by the floor and consume the counts of other live instances of the same class.

Fix, contained to debug.ts as you proposed: a WeakSet of currently-counted targets. trackStub counts only when the target is newly added, untrackStub decrements only when the delete actually removed one — so repeat disposal is a no-op.

WeakSet rather than Set deliberately: a strong reference would keep every tracked target alive for the process lifetime, which is a leak inside the leak detector and would make the counts meaningless. The tradeoff is that a target collected without disposal never decrements — but that is already true today, since nothing decrements without a dispose call.

debug.ts had no tests, so this adds six: the shared-target double dispose (yours), double tracking as a defensive case, untracking a never-tracked target, per-class independence, and entry removal at zero. Two fail at this sha — the double-dispose case and the double-track case; the other four describe behavior that is already correct and pass at both shas, which is what makes the two failures meaningful rather than a blanket red. Full rpc suite: 68 passing, from a 62 baseline.

I also took your secondary point about acceptWebSocketSession and added the comment there — that [Symbol.dispose] fires per session on a target that keeps serving, so future cleanup should not be wired to it. That seemed worth pinning in the source rather than leaving to the next reader, since the hazard is invisible at the call site.

Branch: https://github.com/3x3xX3N0N/computer/tree/fix/rpc-stub-tracker-identity — not opening a PR, per CONTRIBUTING.md.

One note in case it is useful for triage: this issue reads as unanswered partly because its comment count is inflated. Seven of the eight comments here are off-topic spam, and the one substantive reply is you redirecting a timezone question that belonged on #57. I nearly skipped it for that reason before actually reading them.

[wellsashley00]

🤝🙌✨ 讨论区比 Issue 更适合提问吗

[dunncharles0112]

😄 插件机制扩展性够不够

[wellsashley00]

🔥🧠 Issue 模板帮了大忙

[wellsashley00]

😄🙌🧪 模型输出不稳定时你们怎么约束

[rajpreetcodes]

WeakSet over Set is right for exactly the reason you give: a leak detector holding strong references would misreport by design. The source comment on acceptWebSocketSession was the part most likely to bite someone later, glad it's pinned where the hazard lives. And yes, most of this thread is throwaway-account spam, the report plus your confirmation is the whole substance.