Problem
Child processes inherit the parent environment by default. User-defined FIRST_* variables can unintentionally interfere with orchestrator logic.
Code reference:
https://github.com/siphonite/first/blob/main/src/orchestrator.rs#L172
let mut cmd = Command::new(exe);
// ...
cmd.env("FIRST_PHASE", phase);
If a user runs FIRST_CRASH_TARGET=5 cargo test, the Orchestrator will inherit this. When it spawns a child for target=1, it overrides it. But if it spawns a child without explicit overrides (or if new variables are added in the future), the pollution persists.
Impact
- Confusing and hard-to-debug behavior: Test behavior changes based on the user's shell environment in subtle ways.
- Unexpected execution modes: A user might accidentally force a specific crash target for all iterations if logic changes.
- Fragile debugging workflows: Manual override vars might stick around when not intended.
Acceptance Criteria
- Orchestrator explicitly controls which
FIRST_* variables are propagated: Ideally, verify the environment is clean or explicitly un-set known variables before spawning.
- Unexpected or user-defined
FIRST_* vars are cleared or overridden.
- Env contract is documented.
Problem
Child processes inherit the parent environment by default. User-defined
FIRST_*variables can unintentionally interfere with orchestrator logic.Code reference:
https://github.com/siphonite/first/blob/main/src/orchestrator.rs#L172
If a user runs
FIRST_CRASH_TARGET=5 cargo test, the Orchestrator will inherit this. When it spawns a child fortarget=1, it overrides it. But if it spawns a child without explicit overrides (or if new variables are added in the future), the pollution persists.Impact
Acceptance Criteria
FIRST_*variables are propagated: Ideally, verify the environment is clean or explicitly un-set known variables before spawning.FIRST_*vars are cleared or overridden.