Say what clears a deployment id whose claim was never named

[dawsontoth]

A one-string follow-up to #2605, which merged while this was being written.

Claiming a deployment id wins an exclusive mkdir and then records who owns it. #2605 reclaims the directory when that write rejects, but a process death between the two leaves a directory naming nobody — and unattributed is a deliberate permanent refusal, so every retry of that id is refused by its own wreckage with nothing able to clear it.

The message said only that the id was "already claimed by a build that has not named its component yet", which reads like a transient conflict you should retry. It is the opposite: no retry of that id can ever succeed. It now says what the state is and what clears it.

Deployment id <id> is already claimed by a build that has not named its component yet.
If no deploy of any component is in flight, that directory is abandoned and has to be
removed by hand; deploying again without a deployment_id mints a fresh id

Closing the underlying window needs the claim and its owner to be one recoverable transaction, which is deferred to #2315 step 5 — that step now carries @kriszyp's two designs plus a third (build at .deploy-staging/.claiming-<uuid>/, write the sidecar, then rename onto the id, so the directory only ever appears already attributed).

For the human reviewer

No open judgment calls. The one thing worth a second's thought is whether "removed by hand" is the right advice to put in an operator-facing string, given the directory is under a dot-prefixed staging path — the alternative is to say nothing about it and only mention minting a fresh id.

The first revision also added a code comment explaining the refusal. @dawsontoth pointed out that the string is what the operator actually sees, so the context belongs there and nowhere else — and the block comment directly above already states the part about nothing on disk separating the two cases. It was dropped; the diff is now the string alone.

Verification

Written and verified on the #2605 branch before that PR merged: npx mocha "unitTests/components/deploy*.test.js" 197 passing, the full unitTests/components/*.test.js sweep 885 passing with only the 5 pre-existing /private/var realpath failures, plus tsc --noEmit, lint:required and the stage/activate integration suite 7/7. Cherry-picked onto main here, and the resulting components/Application.ts is byte-identical to the version those runs covered (diff against 29a1d8e6b). Not re-run in this worktree, which has no node_modules; CI covers it.

No cross-model review round for this one: it changes one error string, which is below the threshold the review tiering sets for a re-run. #2605 carried 20 rounds over the code around it.

Complexity: easy

[gemini-code-assist]

Code Review

This pull request updates the error handling in components/Application.ts when claiming a deployment directory. It adds an explanatory comment and expands the error message thrown when a deployment ID is already claimed, providing instructions on how to resolve the issue. There are no review comments, and I have no feedback to provide.

[claude]

Reviewed; no blockers found.

[kriszyp]

_{🤖 Reviewed with Codex}