Stabilize Pi settings process test budget - #2342
Merged
ymichael merged 1 commit intoAug 24, 2026
Merged
Conversation
ymichael
deleted the
bb/ci-flake-fix-provider-pi-settings-process-timeou-thr_h6jh3anmc4
branch
August 24, 2026 17:24
ymichael
added a commit
that referenced
this pull request
Aug 24, 2026
## What was wrong The Pi lifecycle test coupled two separate contracts. To prove that a failed construction leaves no child, it requested a permanently mismatched model. Production correctly treats an initial mismatch as a transient auth race and retries eight times, so this single lifecycle assertion launched nine real Node children in series and imported the real Pi extension nine times. The test asserted only that more than one child spawned and that all children exited; it did not need nine real processes to prove cleanup. Under packages-shard contention, those avoidable serial launches crossed the harness's unchanged 60-second response deadline and produced `no response to thread/start` in the [failed packages job on PR #2349](https://github.com/get-bb/bb/actions/runs/32773414046/job/97578813957). ## What changed The retry policy and real-process lifecycle coverage are now separate: - `runPiTransientAuthConstruction` contains the unchanged production policy and accepts injected construction, discard, closed-state, and wait operations. A zero-process test deterministically proves one initial attempt plus eight retries, eight failed-attempt discards, and propagation of the ninth error. - The existing real-process transient-mismatch test still proves that a mismatched child is killed, a replacement child succeeds, and no construction-time session error leaks. - The failed-construction lifecycle test now uses a fake-Pi fault that exits before its first response. It launches one real child and still verifies the bridge error, exact spawn count, observed process exit, and no child left behind. - The scratch-file lifecycle case uses the same one-process construction failure and verifies its tool/prompt files disappear after the child exits. The earlier timeout-only changes were reverted: the shared request deadline remains 60 seconds, and the existing lifecycle wrappers remain 90 and 60 seconds. Production retry count, delay, child detachment, and error behavior are unchanged. This does not alter the host-daemon wire protocol, so `HOST_DAEMON_PROTOCOL_VERSION` is unchanged. ## How you verified Before edits, the parent and worker independently confirmed that `HEAD`, `origin/main`, and `git merge-base HEAD origin/main` all equaled `21cb6b68b8fdffe2cd576f11c8af500f98d22c11`, with a clean worktree. Exact GitHub issue/PR and bb thread searches found no overlapping lifecycle fix; PRs #2337 and #2342 cover different provider-pi signatures. The original coupled test reproduced the exact CI error under 256 CPU competitors at 61.288 seconds: `Error: no response to thread/start`. With the structural split and the original clocks restored, the identical stress command passed with 150 milliseconds of lifecycle test time (7.73 seconds total including imports). The deterministic nine-attempt policy test completes in 1–2 milliseconds. - Focused retry-policy and failed-construction coverage — 3 passed, 6 skipped - `pnpm exec turbo run test --filter=bb-plugin-provider-pi --force` — 18 files, 105 tests passed - `pnpm exec turbo run typecheck --filter=bb-plugin-provider-pi --force` — 4 Turbo tasks passed - `pnpm exec turbo run build --filter=@bb/server --force` — 4 Turbo tasks passed - `pnpm exec oxfmt plugins/provider-pi/src/bridge/rpc-session.retry.test.ts --check` — passed - `git diff origin/main --check` — passed > AGENT GENERATED: by GPT-5.6-Sol
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
1 participant
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.
What was wrong
The Pi settings integration test exercises four required process constructions in series—initial start, resume, fork helper, and fork target—but its enclosing Vitest budget was only 30 seconds. Each construction launches a real Node child and imports the real Pi extension seam, so CPU-starved CI can delay all four without any bridge hang or behavioral failure. The failed packages job expired at that wrapper while the unchanged test passed in 6.5 seconds in a near-concurrent rerun. Controlled reproduction confirmed scheduler sensitivity: with 256 CPU competitors, start took 7.57 seconds, resume another 7.38 seconds, and fork's two constructions another 15.29 seconds; the turns and stop took only 46 milliseconds, all process work completed at 30.28 seconds, and Vitest reported the expected 30,000 ms timeout at 30.37 seconds.
What changed
bridge.settings.test.tsnow gives that four-construction test the same 60-second process budget already used by the Pi conformance wrapper. A named constant and comment document why this test has the larger budget. Every assertion and exercised start/resume/fork path is unchanged; no production, wire, CLI, or documentation behavior changed, soHOST_DAEMON_PROTOCOL_VERSIONis unchanged.How you verified
The parent and worker independently verified before edits that
HEAD,origin/main, andgit merge-base HEAD origin/mainall equaledb735da19e3cf340ae19beb60f9b4e6ad31e98783, with a clean worktree. Fresh GitHub issue/PR and bb thread searches found no matching open fix. The identical 256-competitor Turbo stress that failed before passed after the change in 30.21 seconds with every assertion intact.pnpm exec turbo run test --filter=bb-plugin-provider-pi --force -- --run src/bridge/bridge.settings.test.ts— 1 test passedpnpm exec turbo run test --filter=bb-plugin-provider-pi --force— 17 files, 104 tests passedpnpm exec turbo run typecheck --filter=bb-plugin-provider-pi --force— 4 Turbo tasks passedpnpm exec turbo run build --filter=@bb/server --force— 4 Turbo tasks passedgit diff --check— passed