Wait for quiet after exact replay completion - #2459
Merged
ymichael merged 1 commit intoAug 26, 2026
Merged
Conversation
Reaching the planned accepted-event count is only a lower bound, so exact replay now also waits for the existing quiet period before closing stdin. Keep the delayed planned-tail guard and cover a valid delayed extra event.
ymichael
deleted the
bb/post-merge-fix-prevent-exact-replay-false-greens-thr_hyxizk444y
branch
August 26, 2026 19:00
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.
Human comments
What was wrong
Exact current-lane parity replay treated reaching the planned grammar-accepted event count as proof that the stream had ended. That count is only a lower bound: a bridge can emit another valid event shortly after the recorded tail. Closing stdin immediately at the count discarded that delayed event and let exact replay falsely pass with no stall.
What changed
At the shared
replayRecordingsettlement boundary, exact replay still waits for every planned event and then also waits for the existing output quiet period before closing stdin. Non-exact cross-version replay retains its existing quiet-period termination and does not gain a planned-count requirement.The real-child regression continues to delay the planned tail beyond the quiet window, preserving missing-tail coverage, and then emits a fifth valid context-usage event after the planned count. The test requires all five events with no stalls or grammar violations.
This changes only the published provider-bridge testing harness behavior and documentation for the existing
settleMsoption. There is no new API member, CLI/config surface, persisted state, provider exception, or server↔host-daemon wire change, soHOST_DAEMON_PROTOCOL_VERSIONremains unchanged.@get-bb/plugin-sdk0.4.22 is still unpublished and its publish job will include the changed testing bundle, so another SDK version bump is not needed.How you verified
Before the production change, the focused real-child regression failed twice with four observed events versus five expected; the planned prefix and tail arrived, no stall was reported, and only the valid delayed fifth event was missing. After the fix, the focused regression passed.
pnpm exec turbo run test --filter=@bb/provider-bridge-protocol --filter=@bb/provider-parity --filter=@get-bb/plugin-sdk --force— 238 protocol, 56 parity, and 219 plugin SDK tests passed after rebasing onto currentmain.pnpm exec turbo run build typecheck --filter=@get-bb/plugin-sdk --filter=@bb/domain --filter=@bb/provider-bridge-protocol --filter=@bb/provider-parity --force— 8/8 tasks passed.node packages/plugin-sdk/scripts/check-npm-version-guard.mjs— passed; 0.4.22 is unpublished and will ship this bundle.git diff --check origin/main...HEAD— passed.Follow-up to #2440.