You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test-acq: 'msb auto-detect falls back to msb' fails locally when a real sbx is on PATH (PATH-robustness) #217
The offline test msb: auto-detect falls back to msb (scripts/test-acq, ~line 517) is environment-dependent: it passes in CI (clean PATH) but FAILS on a developer machine that has a real sbx binary installed on PATH (e.g. via brew install docker/tap/sbx). Expected msb, got sbx.
Root cause
The test removes the stubbed sbx (rm -f "$STUBDIR/sbx") to simulate "sbx absent," then asserts _auto_detect_backend falls back to msb. But it only removes the stub from $STUBDIR — the developer's realsbx is still earlier/later on PATH, so _auto_detect_backend finds it and returns sbx. The test implicitly assumes no real sbx exists on the host.
# scripts/test-acq (~505-517)
(
...
rm -f "$STUBDIR/sbx"# removes the STUB only; real sbx on PATH remains
detected=$(_auto_detect_backend)
assert_eq "msb: auto-detect falls back to msb""msb""$detected"# got 'sbx'
)
Impact
CI is unaffected (hosted runners have no real sbx), so this is not a merge blocker.
But it produces a spurious FAIL for any maintainer running ./scripts/test-acq locally with sbx installed — noise that can mask real failures and undermines "run the suite locally before pushing."
Fix (make the test PATH-robust)
Pin PATH to just the stub dir for the auto-detect subshells so only the stubbed binaries are visible, e.g.:
(
export PATH="$STUBDIR"# only stubs are discoverable
rm -f "$STUBDIR/sbx"
...
)
or otherwise neutralize the host PATH inside the detection subshells (the suite already prepends $STUBDIR; the fix is to make it the only entry for the detect tests). Apply to both the "prefers sbx" and "falls back to msb" cases so detection is deterministic regardless of host tooling.
Provenance
Found while validating the acq git-identity/path-preflight change (#216) on a dev machine with sbx 0.35.0 installed. Pre-existing on main; not introduced by that PR (confirmed via git stash). Filing so the local-dev noise is tracked, not forgotten.
Cross-linking: this is gap H in the acq backend-parity effort (docs/explorations/acq-backend-parity.md). No scope change — the parity map adopts the fix already proposed here (pin PATH="$STUBDIR" in the auto-detect subshells so detection is deterministic regardless of host tooling). Filed for traceability alongside the new parity issues (#224 gap A, #225 gap B, #226 gap C, #227 gap J).
Grooming update (2026-07-31): split the two local-only failure classes.
msb: auto-detect falls back to msb — root cause confirmed: _auto_detect_backend runs command -v sbx, which finds a real sbx on a developer's base PATH and returns sbx instead of the expected msb (the test removes the stub sbx but not a system one). Fixed in PR test(acq): make the offline suite host-agnostic so it passes locally on any backend (#217) #249 by constraining that subshell's PATH to the stub dir + coreutils. CI unaffected (runners have no sbx).
5 remaining local failures (msb: workspace mounted at same guest path, multi-ws mounts primary/extra, multi-ws start dir, single-ws records) — a different local-only class: on this dev machine the msb-provision exec-readiness probe times out in the harness (the provision path waits on _acq_msb_wait_for_exec_ready). These pass in CI (verified: Pre-commit green on main sha fc7a93e / 0d2bbd0). Keeping this issue open scoped to that provision-readiness robustness in the local harness.
Once #249 merges, #217's original command -v sbx PATH-robustness complaint is resolved; the residual is the provision-readiness harness item above.
Activity
mogul commentedon Jul 24, 2026
Cross-linking: this is gap H in the acq backend-parity effort (
docs/explorations/acq-backend-parity.md). No scope change — the parity map adopts the fix already proposed here (pinPATH="$STUBDIR"in the auto-detect subshells so detection is deterministic regardless of host tooling). Filed for traceability alongside the new parity issues (#224 gap A, #225 gap B, #226 gap C, #227 gap J).AI-assisted (OpenCode).
feat(acq): detect stale sandboxes + acq kit check|update (#236)
feat(acq): detect stale sandboxes + acq kit check|update (#236)
wz-gsa commentedon Jul 31, 2026
Grooming update (2026-07-31): split the two local-only failure classes.
msb: auto-detect falls back to msb— root cause confirmed:_auto_detect_backendrunscommand -v sbx, which finds a real sbx on a developer's base PATH and returnssbxinstead of the expectedmsb(the test removes the stub sbx but not a system one). Fixed in PR test(acq): make the offline suite host-agnostic so it passes locally on any backend (#217) #249 by constraining that subshell's PATH to the stub dir + coreutils. CI unaffected (runners have no sbx).5 remaining local failures (
msb: workspace mounted at same guest path,multi-ws mounts primary/extra,multi-ws start dir,single-ws records) — a different local-only class: on this dev machine the msb-provision exec-readiness probe times out in the harness (the provision path waits on_acq_msb_wait_for_exec_ready). These pass in CI (verified: Pre-commit green onmainsha fc7a93e / 0d2bbd0). Keeping this issue open scoped to that provision-readiness robustness in the local harness.Once #249 merges, #217's original
command -v sbxPATH-robustness complaint is resolved; the residual is the provision-readiness harness item above.test(acq): canonicalize host paths in msb provision asserts (#217)
feat(acq): detect stale sandboxes + acq kit check|update (#236) (#241)
test(acq): isolate PATH in the msb auto-detect-fallback test (#217)
test(acq): canonicalize host paths in msb provision asserts (#217)
test(acq): make the offline suite host-agnostic so it passes locally …
feat(acq)!: sbx↔msb backend parity, incl. live openchamber-on-msb (om…