From b763ebff5c11522dea2a961866e77d8f2e5c2206 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Fri, 4 Sep 2026 11:46:39 +0700 Subject: [PATCH] =?UTF-8?q?Features:=20#293=20=E2=80=94=20the=20third=20do?= =?UTF-8?q?or=20into=20the=20teardown=20leak?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 11-Features.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/11-Features.md b/11-Features.md index 2908c26..85ca712 100644 --- a/11-Features.md +++ b/11-Features.md @@ -3496,6 +3496,18 @@ these two backwards would destroy real work, so the tests pin the separation fro normal-release test asserts the branch delete is *never* called, and the failed-spawn test asserts the deleted branch is the exact one `add()` created. +**A third door into the same leak, found later.** Tearing a member down runs three steps: close the +pane, close its tab, then release the generated credential-scrub directory. The first and third were +wrapped; closing the tab was bare. By the time that step runs the pane is already gone, so a failure +there is cosmetic tidying — but it threw, and the throw travelled up into the release path *before* +the worktree removal that the fix above wraps. The session was already deregistered by then, so a +second stop is a no-op: same unrecoverable leak, plus the scrub directory and its `allowed N of M` +report. Closing the tab now logs a WARN naming the tab and carries on. + +Closing the **pane** still propagates its failures, and that difference is the point. That step is +the one whose failure means the teardown may genuinely not have happened, so reporting it as done +would be a lie. The tab is not. + ## A chained second question no longer kills its own ticket **What.** A member that calls `fleet_ask` twice in one turn — asks, gets an answer, then asks again —