Repository navigation
D: real-Docker export through a recovery handle after a restart (#51) - #109
Merged
Merged
Conversation
The last "Done when" item of #51: removal by recovery handle had a real-Docker case, but export by handle only ran against the fake Docker CLI. An earlier Node process now allocates real task storage and exits without releasing it; this process recovers it, exports through the handle (refused without F's baseline, failed with a wrong one, correct with the right one, storage unchanged, no export container left), then removes the storage by that handle. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #51. Items 1–6 of #51 have already merged (#69, #70, #71, #72, #73, #76). This PR covers the last "Done when" gap.
The gap
The "Done when" list for #51 asks the real-Docker suite to cover "recovery handles being accepted by export and removal after a simulated restart". Removal by handle already had a real-Docker case: "recovers only its own runner after a restart…". Export by handle ran only against the fake Docker CLI, in
test/agent-storage-async.test.ts.What this adds
One test in
test/agent-container.test.ts, which runs in thereal-dockerjob: "exports through a recovery handle after a restart, then removes the storage by that handle".prepareTaskFilesystems, then exits without releasing anything. This process never held the allocator value, its trusted clone or its live allocation.recoverLeftovers(runnerOwner). Recovery removes nothing and returns exactly one storage handle.metadataBaseline, the export is refused before anything runs.removeTaskFilesystems(handle)removes the keeper and both volumes, and the handle is spent.Verification
tscis clean.resolveMetadataBaselineto ignore the baseline that F passes for a recovery handle. The new test then failed with "the metadata changed since the storage was seeded". I reverted the change afterwards.Review
An independent review subagent found no blocking defects.
Applied:
report.removedis empty.finallysweep unable to throw.modulehelper tospecifier.Declined:
🤖 Generated with Claude Code