onRpcBroken callbacks are retained for the session's lifetime after their import is disposed (and fire at teardown)
维护者通常 5 天内回复
@ndisidore 已经在做这个了。
开始于 2026年10月23日。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- typescript
调研方向
运行自包含的 node repro.mjs,以观察仍被保留的回调以及延迟触发的 teardown。然后阅读 src/rpc.ts,重点关注 ImportTableEntry.onBroken()、resolve()、abort() 和 dispose();完成的标准是,已 dispose 的 imports 不再保留回调,也不再在之后触发回调,同时保持 session-abort 的顺序和现有的注册行为不变。
由索引模型根据 Issue 内容生成。
描述
Version: capnweb 0.10.0 (tag 92baaed), Node 24.
Summary: an onRpcBroken callback registered on an import entry whose resolution is unset — which includes ordinary remote capability stubs, not just pending promises — is retained in the session-level RpcSessionImpl.onBrokenCallbacks list after the capability is fully disposed and released. The callback then fires at session teardown with the teardown error, long after the capability it observed was cleanly disposed. Since session abort doesn't clear the list either, the closures stay reachable for as long as the RpcSessionImpl remains reachable.
Mechanism (at the tag, src/rpc.ts):
ImportTableEntry.onBroken()pushes the callback ontosession.onBrokenCallbacksand records the index in the entry'sonBrokenRegistrations.- On final disposal of an entry with no resolution,
dispose()→abort()setsthis.onBrokenRegistrations = undefinedwithout deleting the corresponding entries fromsession.onBrokenCallbacks, thensendRelease()removes the entry. - This is asymmetric with
resolve(), which explicitly reconciles the registrations: it deletes the old session slot when the callback moves elsewhere, or removes a redundant newly-added same-session slot while preserving the original ordering. The disposal path performs no equivalent cleanup. - The comment in
abort()("The RpcSession itself will have called all our callbacks") holds when the session aborts the entry, but not when localdispose()callsabort()first.
Observable consequences:
- One strong callback reference (plus anything the closure strongly captures) accumulates per registration for as long as the
RpcSessionImplis reachable — unbounded on a long-lived session with capability churn. - Callbacks belonging to cleanly-disposed capabilities still fire at session teardown, and with the teardown error rather than any disposal-related reason.
- The retention is invisible to
getStats(), which reports only the import/export tables — those return to baseline.
Reproduction (self-contained, node repro.mjs in a project with capnweb 0.10.0 installed):
const { RpcSession, RpcTarget } = await import("capnweb");
// Trivial in-memory transport pair.
function transportPair() {
const mk = () => ({ queue: [], waiter: null, closed: null });
const a = mk(), b = mk();
const side = (inbox, outbox) => ({
send(message) {
if (outbox.waiter) { outbox.waiter.resolve(message); outbox.waiter = null; }
else outbox.queue.push(message);
},
async receive() {
if (inbox.queue.length > 0) return inbox.queue.shift();
if (inbox.closed) throw inbox.closed;
inbox.waiter = Promise.withResolvers();
return inbox.waiter.promise;
},
abort(reason) {
inbox.closed = reason;
if (inbox.waiter) { inbox.waiter.reject(reason); inbox.waiter = null; }
},
breakNow(reason) { this.abort(reason); },
});
return [side(a, b), side(b, a)];
}
class Thing extends RpcTarget { poke() { return "ok"; } }
class Main extends RpcTarget { getThing() { return new Thing(); } }
const [clientTransport, serverTransport] = transportPair();
void new RpcSession(serverTransport, new Main());
const client = new RpcSession(clientTransport);
const main = client.getRemoteMain();
console.log("baseline stats:", client.getStats());
let disposedFires = 0;
for (let i = 0; i < 6; i += 1) {
const thing = await main.getThing(); // fresh capability, one handle
thing.onRpcBroken(() => { disposedFires += 1; });
await thing.poke();
thing[Symbol.dispose](); // fully released
}
await new Promise((r) => setTimeout(r, 50));
console.log("stats after 6 acquire/dispose cycles:", client.getStats()); // back to baseline
console.log("fires while session healthy:", disposedFires); // 0
clientTransport.breakNow(new Error("connection lost"));
await new Promise((r) => setTimeout(r, 100));
console.log("fires at session death, all from disposed imports:", disposedFires); // 6
Observed output: getStats() returns to { imports: 1, exports: 1 } after the six acquire/dispose cycles, zero callbacks fire while the session is healthy, and all six fire when the transport later breaks.
Why this looks like a bug rather than intent: the README describes onRpcBroken as monitoring a stub's "brokenness" and says the callback runs if something causes all further method calls and property accesses on that stub to throw. The follows-the-resolution behavior (which the test suite pins, and which resolve()'s session-array reconciliation supports) stops applying once the capability is fully released. Either defensible disposal semantic — unregister on disposal, or treat disposal as breakage and fire immediately with the disposal reason — differs from the current behavior of staying silent at disposal and firing much later with the later session-abort error. No test or example appears to pin the current post-disposal late fire.
Fix sketch: mirror resolve()'s cleanup on final disposal — delete the entry's registrations from session.onBrokenCallbacks before discarding onBrokenRegistrations. One care point: the deletion should distinguish healthy local disposal from session-abort reentrancy (a callback that disposes another entry mid-iteration must not delete callbacks that haven't fired yet), and existing tests pin global registration order across entries.
Context: found while building a subscription surface (client-passed observer capabilities, one onRpcBroken per subscription for reaping) on a long-lived Unix-socket session. Our registrations are bounded per connection and the callbacks idempotent, so this isn't urgent for us — filing for correctness. Checked for prior reports: #153/#168 (receive-loop retention, fixed in 0.10.0), #154, #151, and #172 are adjacent but concern different lifecycles.
- 主要语言
- TypeScript
- 星标
- 4k
- 派生
- 150
- 平均合并
- 3 天 12 小时
- 30 天内合并 PR
- 2
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
cloudflare/capnweb 的其他 Issue
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
cloudflare/capnweb#269 · 2 条评论 ·
维护者通常 5 天内回复
-
难度 3/5 1-2 天 新手友好度 48/100
cloudflare/capnweb#260 ·
维护者通常 5 天内回复
-
onRpcBroken should return a Disposable so registrations can be undone可能重新可做 关联的 PR 已关闭且未合并。 未关闭enhancement
难度 4/5 3-5 天 新手友好度 35/100
cloudflare/capnweb#234 · 1 条评论 ·
维护者通常 5 天内回复
-
support `Map` serialization type可能已有人在做 @srikrsna 于 86 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 55/100
cloudflare/capnweb#230 ·
维护者通常 5 天内回复
-
难度 3/5 1-2 天 新手友好度 68/100
cloudflare/capnweb#228 ·
维护者通常 5 天内回复
查看 cloudflare/capnweb 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
components-web-app/docs#311 ·
-
难度 2/5 1-3 小时 新手友好度 82/100
NEARBuilders/everything-dev#678 ·
维护者通常 1 天内回复
-
难度 1/5 1-3 小时 新手友好度 90/100
formbricks/formbricks#9881 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复