mixed-signals

Why Rendering settled historical data creates live Signals for every reflected field, and observing them queues large watch frames even though the server already knows those values can never change. The server should express that invariant directly so clients avoid inert subscriptions without relying on application-specific heuristics or signal-core internals. Final API The public API remains . A signal already final when serialized is . A signal finalized later is announced as , queued and debounced for one second. Existing update modes remain unchanged: omitted = replace, , , and . The only new mode is . Sealing removes the server subscription immediately. The client preserves the current value, drops watched and active state, and sends no . Forwarders remember upstream seals, relay them to current recipients, and answer later watches locally. Finality remains permanent across signal state transfer and reconnects. Final signals continue to serialize inline because they are not strongly retained by watch state. Implementation The server coalesces pending seals behind one timer while immediately tearing down subscriptions. The client handles as an update mode without changing the established delta encodings. Forwarding rewrites, relays, and caches the seal state. Architecture documentation, generated API documentation, tests, and the changeset reflect the final wire contract. Verification (269 tests), , , , and pass.

Why Serializing a signal always inlined its value, so any value that reached a client twice was paid for twice. The natural way to answer "give me the diff" without shipping a second copy is to return the reflected signal itself — . But the reply inlined the whole payload again, right next to the update the client had already received. In Claudex that was a 474 KB diff crossing the wire twice in adjacent frames. What now emits a bare (no ) when it can prove the client already holds that exact value: 1. the last value sent to that client for that signal is identical, and 2. the client still has a live subscription to it. Both halves matter. The last-sent value says the bytes arrived; the subscription says the client still has somewhere to put them — watched signals are held strongly client-side (), so a subscription rules out the signal having been collected out of the client's cache and the ref resolving to a fresh signal. The client reviver already handled -less refs, so only the server half was missing. Model refresh () deliberately re-inlines a model's own signals — a refresh means the client stopped trusting its copy, and a ref back to that copy is worthless. That's what is for; two existing tests catch it if you remove it. Measured The e2e test returns a 50,000-char signal from an RPC method. Before: ~50,024 bytes. After: 20 bytes, value intact and still live (a later server-side mutation propagates). Suite 260/260, typecheck and lint clean.

Problem A connection can go half-open: the network path is gone (laptop sleep/wake, NAT or LB idle expiry, server died without sending a FIN) but no event fires, sometimes for minutes. TCP only notices when retransmits give up, and browsers don't expose WebSocket ping/pong to JavaScript, so from the page's point of view the socket just goes quiet. A made on such a socket sits in the map forever: nothing rejects it until a close event or an explicit . We hit this in production. A tab held a dead socket for ~4 minutes before the close event finally arrived, and a call sat pending the whole time with no error surfaced anywhere. The README already tells callers to wrap in their own timeout; has the same gap, but it can't be fixed from outside the library — is private, and an app-level wrapper around a call can't tell a slow response from a dead transport. Fix Treat the transport as disconnected when the oldest pending call and the newest inbound frame are both older than (default 30s). This goes through the existing path (pending calls reject, rejects, subscription replay arms) plus a call to the transport's new optional so the dead socket is torn down. Host reconnect logic picks up from there the same as for a real close. Requiring both clocks to be old is what keeps false positives out: any inbound frame (a result for another call, a signal update, a root snapshot) resets the clock, so a slow response on an otherwise live connection is fine a call sent on a long-quiet but healthy connection starts its own clock, so old silence doesn't instantly condemn it Details: checks are deadline-scheduled, not polled. Calls and inbound frames only push the deadline later, so an armed timer never needs rescheduling; it wakes, recomputes, and sleeps the difference. No timer exists while nothing is pending, and it's unref'd so it won't hold a Node process open. is optional and additive; existing transports are unaffected. disables detection. Default This is on by default: a call that hangs forever is a bug for every network consumer, and the silence gate makes false positives unlikely. The case that loses is a transport that can't go half-open but can legitimately block — e.g. a MessagePort to a worker doing 30s+ of synchronous work while a call is pending. That's what is for, and the TSDoc calls it out. Happy to flip this to opt-in if you'd rather ship it that way; the mechanism is the same. Testing Six new tests in : rejection + transport close after total silence, deferral when inbound frames arrive, disarming while nothing is pending, , the 30s default, and interaction with . Full suite passes (237). , , and are clean; README regenerated with . 🤖 Generated with Claude Code