RpcServer disconnects cannot be observed without competing with cleanup

[schickling-assistant]

RpcServer.Protocol.disconnects is exposed as a Queue.Dequeue<number>, but RpcServer.make also consumes that queue internally to interrupt a disconnected client's in-flight handlers. An application that takes from the queue to observe passive disconnects competes with the server and can prevent handler cleanup.

Reproduction

https://github.com/schickling-repros/2026-09-effect-rpc-disconnect-observer

bun install
bun run repro

The repro uses a minimal in-memory protocol and runs a control plus a competing-observer case. It synchronizes on queue takers and handler lifecycle signals directly; no timing sleeps are involved.

Output:

control: both disconnected handlers were interrupted
competing observer: observer stole client 1; only client 2 was interrupted

Expected

There is a non-destructive way to observe passive client disconnects while preserving RpcServer.make's lifecycle handling.

Actual

The event-like API is the same work-sharing queue used by the server. Queue.take(protocol.disconnects) can steal a notification, so server.disconnect(clientId) is not called and that client's handler remains active. Protocol.clientIds is a snapshot and cannot provide equivalent event observation.

An additive callback on RpcServer.make (invoked after the server handles a disconnect) could expose this without changing the Protocol transport shape or queue semantics.

This was reproduced with effect@4.0.0-rc.112, and the same single-consumer flow is present on current main.

Related: #7342 fixed another path where a lost disconnect prevented handler cleanup.

Posted on behalf of @schickling

field	value
agent_identity	dev3.direct.omp.pdvr6amr
session	unknown
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.2.11
agent_runtime	OMP 18.2.11
agent_model	openai-codex/gpt-5.6-sol
worktree	2026-09-effect-rpc-disconnect-observer/main
tooling_profile	dotfiles@b0f94e3-dirty

[84dnnvbdvp-debug]

There is one lifecycle constraint on the suggested callback that seems worth pinning in the regression before choosing the API shape.

Current RpcServer.make has a single long-lived child fiber whose loop does Queue.take(disconnects) and then server.disconnect(clientId). That makes the internal consumer not just a notification path but the liveness mechanism for all later disconnect cleanup.

If an additive observer is simply sequenced into that loop after server.disconnect(clientId), it can recreate the same class of leak in a different way: an observer effect that never completes stalls consumption of every later disconnect, and an observer that fails/defects can terminate the one child loop unless that failure is isolated. The first client's cleanup may already have happened, but subsequent clients can again be left with live handlers.

So I think “non-destructive observation” should include control-path isolation, not only “doesn't steal from the queue.” A useful regression would disconnect two clients while the observer for client 1 either (a) blocks forever or (b) deliberately defects/fails; client 1's handler must still be interrupted and client 2's later disconnect must still clean up its handler. Observer failure/reporting/backpressure semantics can be chosen separately, but they should not own the server's cleanup liveness.

That leaves implementation freedom: a callback can be forked/isolated, or the server can publish to a separate broadcast/event surface after internal cleanup. The important invariant is that passive observation cannot delay or terminate the internal disconnect-consumer loop.