Skip to content

test-acq: 'msb auto-detect falls back to msb' fails locally when a real sbx is on PATH (PATH-robustness) #217

Closed

Description

@wz-gsa

Summary

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 real sbx 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.

Related

Activity

  1. mogul commented on Jul 24, 2026

    @mogul
    Contributor

    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).

    AI-assisted (OpenCode).

  2. wz-gsa commented on Jul 31, 2026

    @wz-gsa
    ContributorAuthor

    Grooming update (2026-07-31): split the two local-only failure classes.

    1. 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).

    2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions