Repository navigation
fix(minimald,sandbox): a task that ends during its network attach reports its own exit status, not a - #3365
Draft
minimal-foundry[bot] wants to merge 3 commits into
Conversation
minimald holds its task process behind its own type, so it needs the ended-aware attach without a hakoniwa::Child in hand.
A task that exited while its network was being attached took its namespace with it, and the refused attach killed the task and showed "connecting the task's network failed". attach_or_reap now asks whether the process ended, keeps it unreaped, and owes no guard.
…t-ends-during-its-network-attach-repor
Contributor
|
Important Review skippedBot user detected. To trigger a single review, invoke the
|
Member
|
/revise make Evidence: the PR body says Do:
|
This branch has not been deployed
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.
Defect
Fixes #3350
crates/sandbox/src/lib.rscrates/minimald/src/exec/process.rscrates/minimald/src/exec/tests.rsTask marker
Proof
A min task run whose process exits before its network attach completes now ends with the process's own exit status. minimald does not kill the process and does not print "connecting the task's network failed". A refused attach of a process that still runs stays an error and stops the task.
Notes from the agent: sandbox: PlannedLaunch::attach_unless_ended is now pub, and it has a new test whose name the test line matches. minimald: Reapable gains has_ended (try_wait on hakoniwa::Child). attach_or_reap calls attach_unless_ended a 8000 nd returns Option. HakoniwaProcess::new and NetRelease::new take Option. The new minimald test uses a fake child, so it proves that attach_or_reap does not reap the ended process and owes no guard. No test here runs a real container to read the exit status end to end. cargo clippy -p minimald --all-targets gave no warnings. I did not run just clippy-strict.
Tests
cargo test -p sandbox attach_unless_endedcargo test -p minimald a_task_that_ended_during_its_attach_reports_its_exitcargo test -p minimald a_refused_task_attach_stops_the_taskVerify
min task run agent-verifytimed out after 1800s, so this PR is a draft.Base
The base branch moved while the coder worked; it was merged in before the tests ran.