GeezerVison

What is the current behavior?

After Chrome DevTools disconnects, the app log fills with:

InspectorServer::Send error: Operation canceled

Since #390 the server closes the client's dispatch_io channel on EOF, but JsV8InspectorClient is never told. sender_ keeps the closed channel, so every later CDP message (each console.log, every Debugger.scriptParsed, …) is serialized, written, and fails with ECANCELED.

Other state is left behind too:

• The V8 inspector session stays alive with the departed frontend's breakpoints and enabled domains. A breakpoint or debugger; hit after DevTools closes, or a disconnect while paused, leaves the app frozen in runMessageLoopOnPause with nobody to resume it.
• Tracing, IO streams and worker sessions are only reset when the next frontend connects.
• The read handler leaks per connection. __block dispatch_io_handler_t receiver references itself under ARC, so the block and its channel are never freed.
• Each AttachRequest opens another listening socket. The CLI re-posts it every 5 s until it sees the port, and again per debug session. Each post called InspectorServer::Init, which bound a new socket on the next free port and never closed it.
• Reconnecting while paused could hang the socket thread. It called disconnect(), which took the isolate Locker there and blocked while the main thread was paused.

What is the new behavior?

InspectorServer

• Each client is a Connection with an id and its own serial queue. Closing it is idempotent and fires the new onClientDisconnected(id) callback. The sender becomes a no-op once the connection is closed, and ECANCELED from writes still queued at close time is no longer logged.
• The self-referencing read block is replaced by a read loop that accumulates each length-prefixed frame until done, so there is no retain cycle and no set_low_water trick.
• Client sockets get SO_NOSIGPIPE.

JsV8InspectorClient

• On disconnect it clears the sender (ignoring stale connection ids, so a late close can't clobber a newer frontend) and resets the frontend's state: IO streams, tracing, worker sessions, and the main session.
• The main-session reset is a sentinel in the frontend message queue, so it is ordered before anything a new connection sends, and it never takes the Locker on the socket thread.
  • Outside a pause, the drain replaces the session directly.
  • Inside the pause loop, which may sit under session_->dispatchProtocolMessage, and where V8 touches every session right after the loop returns, it does setSkipAllPauses(true) + resume(). The session is swapped by the next drain once the loop has fully exited. The pause loop can run on a non-main thread, so the drain won't pump while a reset is pending.
  • This mirrors WorkerInspectorClient's deferred reset.
• On connect, the session is only reset when replacing a still-attached frontend. Otherwise it is either fresh or its reset is already queued by the disconnect. Connect and disconnect run on different connection queues, so a dedicated lifecycle mutex serializes them.
• A session reset drops the departing frontend's still-queued messages, so their replies (whose ids may collide) never reach the next frontend. Messages carry their connection id, and any message read from a connection after it was replaced is dropped.
• The listening socket is opened once; repeated AttachRequests get the same port.
• One client at a time: a new connection closes the previous one, instead of leaving it open but silent while its commands kept running in the new session. Takeover runs on the (serial) accept handler, so back-to-back accepts take over in order. Multi-client support (separate V8 sessions per connection, as Chrome/Node do) can come as a follow-up.
• A replaced frontend's output never reaches its successor. The main session is bound to the connection it serves, and all of its output (V8 replies/events, JS-domain replies, Target events) goes there. The sync message rebinds it, replacing the session first if it served another connection, so a command still executing during a takeover replies to the closed connection. Worker sessions record a frontend generation, bumped with every sender swap, and output with a stale generation is dropped.

Testing

• Full suite: ./run_tests.sh --keep-sim, 1824 specs, 0 failures.
• End-to-end on a simulator, using a small CDP client against TestRunner with a keep-alive entry script and a setInterval console ticker:
  • Idle disconnect: ticks continue and there are zero InspectorServer log lines (previously one Send error per tick).
  • Disconnect while paused (Debugger.pause, held 2 s, then close): ticks stop during the pause and resume ~100 ms after the socket closes. Previously the app stayed paused.
  • Reconnect after both: Runtime.evaluate answers on the fresh session.
  • Takeover: while client A is attached, client B connects. The server closes A, and B's Runtime.evaluate answers.
  • In-flight takeover: A sends a 1.5 s busy Runtime.evaluate, on the main session and on a worker session, and B takes over mid-command. Neither reply reaches B, B's own commands work, and B's Target.setAutoAttach still announces the worker.
  • Repeated AttachRequest: always logs port 18183, with a single listening socket.
  • After five connect/disconnect cycles, the app holds only its listening socket, with no leaked client fds.

Summary by CodeRabbit

• Bug Fixes
  • Improved inspector connection handling when clients connect, disconnect, or replace the active client.
  • Inspector messages are handled more reliably, including incomplete messages and connection errors.
  • Messages and disconnect events from replaced clients are ignored, and inspector session state resets when the frontend changes.
  • Prevented stale worker output from appearing in a newer inspector session.
• Improvements
  • Repeated attach requests reuse the existing inspector listening port.
  • Inspector source-map URLs can be rewritten to runtime paths, with opt-out support.