Found by the claude lane reviewing #258 (issue #241), and grounded by reading rather than inferred.
The gap
ThreadSubscriptionPool.stop(threadId) has exactly one caller: porch-thread-engine.ts's removeWorktree. Its only production caller is cleanup.ts — in the afx CLI process, not Tower's. Tower's own paths hold only stopAll on socket close (thread-backend.ts).
So Tower has no per-thread eviction at all. A thread that leaves global.db keeps its ResumingSubscription open until Tower restarts. Blast radius: one live subscription per thread ever adopted, for the life of the process.
T3codeSessionCache does not have this problem — its #forget drops the entry AND cancels the stream when a thread leaves global.db, with a comment recording that forgetting the bookkeeping while the stream ran on was the bug it fixed. ThreadAdoptionSweeper reconciles in only one direction.
The second symptom, same cause
A stalethread_id in global.db — a row whose thread no longer exists on the server — is re-adopted on every 5s pass and WARNs on each failed attempt, forever. Nothing prunes it and nothing gives up on it.
Suggested shape
ThreadAdoptionSweeper already computes the full thread set per workspace. Give it the pool (or a stop callback) and reconcile the other direction too: any pool entry whose thread id is no longer in the set gets stop().
Take the #threadIds rule with it — a failed read returns null and prunes nothing. Pruning on a locked database would cancel every live subscription in the workspace, which is a far worse failure than the leak.
For the stale-id case, consider a bounded number of adoption attempts per thread id before it is logged once and skipped, so a permanently-dead row does not produce a WARN every 5 seconds for the life of the process.
Not blocking #258
The claude lane called it follow-up-sized and it is: the leak is bounded by Tower's lifetime and does not affect correctness of any turn. Filed rather than folded in so #258 does not grow on the critical path to spec 146 phase 14.
Refs #241, #251
Found by the claude lane reviewing #258 (issue #241), and grounded by reading rather than inferred.
The gap
ThreadSubscriptionPool.stop(threadId)has exactly one caller:porch-thread-engine.ts'sremoveWorktree. Its only production caller iscleanup.ts— in the afx CLI process, not Tower's. Tower's own paths hold onlystopAllon socket close (thread-backend.ts).So Tower has no per-thread eviction at all. A thread that leaves
global.dbkeeps itsResumingSubscriptionopen until Tower restarts. Blast radius: one live subscription per thread ever adopted, for the life of the process.T3codeSessionCachedoes not have this problem — its#forgetdrops the entry AND cancels the stream when a thread leavesglobal.db, with a comment recording that forgetting the bookkeeping while the stream ran on was the bug it fixed.ThreadAdoptionSweeperreconciles in only one direction.The second symptom, same cause
A stale
thread_idinglobal.db— a row whose thread no longer exists on the server — is re-adopted on every 5s pass and WARNs on each failed attempt, forever. Nothing prunes it and nothing gives up on it.Suggested shape
ThreadAdoptionSweeperalready computes the full thread set per workspace. Give it the pool (or astopcallback) and reconcile the other direction too: any pool entry whose thread id is no longer in the set getsstop().Take the
#threadIdsrule with it — a failed read returns null and prunes nothing. Pruning on a locked database would cancel every live subscription in the workspace, which is a far worse failure than the leak.For the stale-id case, consider a bounded number of adoption attempts per thread id before it is logged once and skipped, so a permanently-dead row does not produce a WARN every 5 seconds for the life of the process.
Not blocking #258
The claude lane called it follow-up-sized and it is: the leak is bounded by Tower's lifetime and does not affect correctness of any turn. Filed rather than folded in so #258 does not grow on the critical path to spec 146 phase 14.
Refs #241, #251