[dawsontoth]

⊙ Problem

drop_component checked disk to decide whether to remove a fork. A worker still loading the application could create its first fork after the drop's last look. That fork had no marker. The absent application was never listed again, so the fork stayed, unlogged, for a same-name redeploy to adopt.

🤔 Does a rare race need a fix?

Yes. It needs a load running during the drop, but a preview's private data must not outlive its drop, and nothing logs it.

💡 Solution

A drop that discards branches now records the removal before changing anything if a fork could still appear. This applies when the root config declares branches or any thread may hold the application. The retry already waits for every holder, so the marker covers a late fork. A marker that covered nothing clears the same way.

⚖️ Alternatives

🤔 Why a durable marker instead of the recheck the issue suggested?

Framing-Verdict: better-alternative-exists (6b1407a5d94f)

I planned the issue's option 3, an in-memory recheck on each worker release. The planning review showed the retry already keeps an empty marker while anything may hold the application, so the marker is cheap. Unlike the recheck, it survives a crash of main or a drop that fails partway.

🤔 Is a marker for an application that never forked acceptable?

Yes. A plain shared application dropped without a restart keeps an empty marker and retries less often until the pool restarts. Nothing is deleted wrongly. Checking only unreported workers missed loads deferred past a report. Only a fork or a declaration can block a drop, so a full disk never blocks dropping a plain application.

Also considered

• Refuse the fork in prepareBranches: races the drop unless every boot takes the component lock.
• Log unmarked directories at start: a keepBranches drop leaves that state on purpose.

🔧 Changes

Fixes #3758. Part of #3042.

• components/operations.ts: dropApplication records the removal when the app has a fork or the new declaresBranches says so, and refuses the drop if it cannot. When only poolMayHold, hadWorker or mainServes holds, a failed record is logged. declaresBranches reads the root config file and answers true when it cannot, as hasRootConfigEntry does. The retry's log line now says it finished a removal, since a marker may have covered nothing.
• resources/branchDatabase.ts: recordPendingBranchRemoval creates the default database's <app> directory when none exists, and flushes the entries naming each directory it marks.
• components/DESIGN.md: the drop_component note records when a marker is written with no fork on disk.

✅ Verification

• Unit (branchRemovalRetry.test.js, a real worker thread): nine new tests; five fail on main (late fork, stale declaration, deferred load, declared drop that cannot record, drop failing after removal). This harness puts the test and default databases in different roots, so the late-fork case also covers a fork outside its marker's root.
• Integration (branched-database-package.test.ts): dropping an application no worker loaded records and clears its removal, counted through the retry's log line.
• Full gates (Linux, at ad291755b): unit main and resources fail the same 4 tests on head and base; integration is 3086/0 against 3085/0. Later commits: targeted suites only.
• Not covered: a real load reaching prepareBranches after the drop's last look; the harness cannot pause a worker there. Also, hadWorker and mainServes alone.
• Known limits (review minors): a power loss can lose the marker when the default storage root was missing two or more segments, or after an earlier failed fsync; a failed speculative write leaves a stale-config late fork unrecorded.
• PR QA: skipped @ 7779da4 — dispatch unavailable in this session.

🤖 Generated with Claude Code

_{🤖 Generated by Anthropic Claude (Opus 5.5); posted via @dawsontoth.}

Release target: v5.4 — fixes code from #3600 and #3763, which is only on main (v5.4); not a backport
Related PRs: #3763 overlaps (merged; this builds on its retry and worker-release wake-ups)
Complexity: moderate

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex,cursor-grok; late=cursor-grok:adjudicated; adjudicated=domain; declined=muse; rounds=6; full=3 @ 7779da4}

_{Review-Attention: study ~13m (critical: branchDatabase.ts; decisions: speculative-marker-fail-open, conservative-census-for-unbranched, fallback-marker-location, unreadable-config-fails-closed) @ 7779da4}

[gemini-code-assist]

Code Review

This pull request ensures that dropping an application with no active fork on disk (but which a worker might still be loading or could potentially fork) correctly records a pending branch removal. It introduces the declaresBranches helper to check the root configuration, speculatively records pending removals under certain conditions (e.g., if a worker pool may hold it), and adds robust integration and unit tests to verify these scenarios. It also ensures directory creation and fsyncing are properly handled when recording pending removals. No review comments were provided, so there is no feedback to address.