ProjectRegistry.removeConnection is reentrant, and the connection registry is keyed by descriptor

[scgopi]

Found during the independent review of #291. Pre-existing — not introduced by that PR — but worth fixing on its own, because the daemon's outbound channels are now keyed by descriptor too, which makes a wrong-descriptor write more consequential than it was.

The interleaving

ProjectRegistry.removeConnection iterates a copy of connectionProjectPaths[id] with an await per store. While it is suspended:

1. Another connection's .openProject of a new path runs joinSidebars.
2. That inserts the departing sidebar into the new store — connectionProjectPaths[X].insert(B) plus storeB.addConnection(X, fdX).
3. The removal loop never sees B, because it is walking a snapshot taken before.
4. close(fdX) runs anyway.

storeB is then left holding X → fdX indefinitely. Every later broadcast for project B goes to whichever connection has since been handed that descriptor number — including a one-shot CLI, which would print the first graphChanged it sees as though it were its own project's.

It needs the app disconnecting at the same instant another client opens a new folder, so it is rare. No deterministic failing test yet — this is reasoning from ProjectRegistry.swift:128-137 and :390-397.

Suggested fix

Two parts, from the review:

• Key the connection registry by connection UUID rather than by file descriptor. Every caller already has the UUID, and it is the identity that is actually stable — a descriptor number is reused the moment it closes. This applies to OutboundChannels as well, whose global map is descriptor-keyed today.
• Re-read the path set after each await in removeConnection, rather than iterating a snapshot taken before suspending.

Why not in #291

#291 is already large and touches the same files; folding a registry-wide re-keying into it would make it unreviewable. Its own descriptor-recycling hazards are closed (open refuses to inherit a dead channel, send refuses an unregistered descriptor, close refuses a descriptor it has no channel for), so this is the remaining structural half rather than an open hole.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BP43ags4cn8fq2ZZdv85J9

[scgopi]

Two further notes from the #291 re-review, both non-blocking there but belonging here.

1. Key connection identity by project path, not graph.id

#291 keys broadcast supersession as graphChanged:\(graph.id). That is correct in the daemon, but graph.id is a LoopGraph's own UUID, and the app identifies a project by its path. If this issue's re-keying goes ahead, both sides should agree on one identity — the canonical project path is the one both already hold, and it survives a graph being reloaded from disk where a regenerated UUID would not.

Worth doing as part of the re-keying rather than separately, since it is the same question: what is a connection's, and a project's, stable name.

2. A valve-dropped client may leak its reader task

This one is the mirror image of the bug #291 fixed, and is worth checking carefully.

When OutboundChannel's backlog valve gives up on a client, it sets isClosing and calls shutdown(fd, SHUT_RDWR). The writer no longer depends on that call to wake — #291 made writes non-blocking precisely because a thread parked inside write(2) on a unix socket is not reliably woken by another thread's shutdown.

But the daemon's reader still parks in a blocking read(2) (readFrameAsync in graphcoded/Sources/main.swift). If shutdown fails to wake a parked read for the same reason it failed to wake a parked write, that connection's Task never returns: removeConnection never runs, OutboundChannels.close never runs, and the descriptor is never closed. The daemon would then leak a task and a descriptor per valve-dropped client.

Nobody has reproduced this — the valve is hard to reach today (a 4 MB backlog against snapshots well under 1 MB). But the assumption it rests on has already been shown false once on the write side, so it should not be trusted on the read side without evidence either way.

Reproduction sketch: drive a client past the backlog budget without reading, then check whether its connection task exits and its descriptor closes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BP43ags4cn8fq2ZZdv85J9