[kixelated]

Problem

#7466 lets the host land gate export CHECK_FAIL_FAST=1. sh/dispatch-query.test.py runs dispatch.sh in subprocesses that inherited it. So under the gate, four tests that expect every lane to finish failed, and test gh runs on every diff. The 17:00 batch failed only on that, ejecting nine healthy PRs. Every later batch would fail the same way.

Approach

The test harness already clears the gate's variables (CHECK_JOBS, CHECK_MODULES, and the Actions ones) before each test. It now clears CHECK_FAIL_FAST too. The fail-fast tests set it explicitly.

Impact

• No public API changes.

Alternatives

• Dropping CHECK_FAIL_FAST from the host. Rejected: it would give up fail-fast to work around a test that leaked its environment.

Follow-ups

• None.

Checks

• With CHECK_FAIL_FAST=1 in the environment:
  • python3 sh/dispatch-query.test.py fails four tests on main and passes all 31 with this change.
• just check passes.

Review

quest review --base origin/main (Codex), round 1 on head d5e427b: no findings.

This lands past the queue with the admin bypass, like #7466 which it repairs: the queue can't land anything until it's fixed.

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[pullfrog]

ℹ️ No critical issues — one minor doc-sync note.

Reviewed changes

• Clears CHECK_FAIL_FAST before each dispatcher test: adds it to the setUp env-pop loop in sh/dispatch-query.test.py:37-39, so the sh/dispatch.sh subprocesses no longer inherit the host land gate's fail-fast setting, and extends the comment to explain why.
• Fail-fast tests still opt in: test_fail_fast_cancels_running_lanes_and_starts_no_more and test_fail_fast_stops_a_serial_run_at_the_first_failure set CHECK_FAIL_FAST=1 explicitly, so clearing it in setUp does not weaken their coverage.

Verified locally against head d5e427b: with CHECK_FAIL_FAST=1 in the environment all 31 tests pass; removing the added key reproduces the reported four failures. sh/js/workspace.test.py, the other file that spawns dispatch.sh, already passes under CHECK_FAIL_FAST=1, so this PR has no further broken instance to fix.

ℹ️ Stale key list in the tracked quest

quest/m0/ci/workspace-test-env.md:11 enumerates the keys sh/dispatch-query.test.py pops as the reference for the shared helper it plans, and pins them to the old line range :33-37. This PR adds CHECK_FAIL_FAST to that set and shifts the lines, so the quest now under-specifies the fix it describes, even though its goal is that sh/js/workspace.test.py stops inheriting "the other gate and CI variables".

Technical details

# Quest key list needs CHECK_FAIL_FAST

## Affected sites
- `quest/m0/ci/workspace-test-env.md:11` — lists `CHECK_MODULES`, `CHECK_JOBS`, `IN_MOQ_DEV_SHELL`, `GITHUB_ACTIONS`, `GITHUB_STEP_SUMMARY`, `GITHUB_BASE_REF` and cites `sh/dispatch-query.test.py:33-37`; the loop now also pops `CHECK_FAIL_FAST` and the line range moved.

## Required outcome
- The quest's enumerated keys match the current `setUp` pop loop, and its line reference is refreshed, so a future implementer does not ship a shared helper that omits `CHECK_FAIL_FAST`.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}