Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

onRpcBroken callbacks are retained for the session's lifetime after their import is disposed (and fire at teardown)

Đang mở
  • Có gì không ổn?
#210 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

@ndisidore đang làm issue này rồi.

Từ ngày 23/10/2026.

  • #248 của @ting-hong-shieh — đã đóng, không merge
  • #250 của @srikrsna — đã đóng, không merge
  • #284 của @nokiyliao — đang mở
  • #286 của @ndisidore — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
typescript
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

Chạy node repro.mjs độc lập để quan sát các callback vẫn được giữ lại và các lần teardown được kích hoạt muộn. Sau đó đọc src/rpc.ts, tập trung vào ImportTableEntry.onBroken(), resolve(), abort() và dispose(); hoàn tất nghĩa là các import đã dispose không còn giữ lại hoặc kích hoạt callback về sau, đồng thời vẫn giữ nguyên thứ tự session-abort và hành vi đăng ký hiện có.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 onto session.onBrokenCallbacks and records the index in the entry's onBrokenRegistrations.
  • On final disposal of an entry with no resolution, dispose() → abort() sets this.onBrokenRegistrations = undefined without deleting the corresponding entries from session.onBrokenCallbacks, then sendRelease() 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 local dispose() calls abort() first.

Observable consequences:

  1. One strong callback reference (plus anything the closure strongly captures) accumulates per registration for as long as the RpcSessionImpl is reachable — unbounded on a long-lived session with capability churn.
  2. Callbacks belonging to cleanly-disposed capabilities still fire at session teardown, and with the teardown error rather than any disposal-related reason.
  3. 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.

Ngôn ngữ chính
TypeScript
Star
4k
Fork
150
Merge trung bình
3 ngày 12 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cloudflare/capnweb

Tất cả issue của cloudflare/capnweb

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.