Merge fix/sdk-7265-wdio-deferred-test-finish-flush - #139
Merged
bsautomation merged 7 commits intoAug 13, 2026
Conversation
…ed (SDK-7265) The binary flow defers each mocha TestRunFinished past the afterEach window and flushes it at the next test's boundary; the worker's last test relies on the single flush from service.after(). sendTestFrameworkEvent swallowed send errors with no retry, so a transient gRPC failure on that flush dropped the finish — orphaning one test that Test Hub reaps at its ~60-min per-test timeout, which stamps the whole (passing) build `timeout`. Retry the flush up to 3x with backoff, surface send success/failure, and re-stash on total failure so a later flush/teardown can retry rather than dropping it. Mirrors SDK-7061's build-stop retry, applied to the test-finish path. Adds a deterministic reproduction test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…then tests (SDK-7265) Review found the re-stash-on-exhaustion guard races the two fire-and-forget flushPendingTestFinishEvent call sites: because the retry loop keeps an invocation in flight, a newer test can take the single pendingTestFinish slot while an older invocation is still retrying, and on exhaustion the guard either re-stashes a stale, already-failed event or drops silently — reintroducing the SDK-7265 symptom under a narrower window. Remove the re-stash entirely (it gave no reliable benefit: nothing re-flushes after service.after(), the last-test path). args is captured locally and the shared slot is only cleared, never written back, so concurrent flushes each retry their own event without clobbering one another. Tests: assert every retry re-sends the same finish (not just call count); drive the retry budget to full exhaustion and assert no re-stash; add a concurrency guard proving an older retrying flush never drops a newer test's finish. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e chain) No behavior change — same retry-with-backoff and exhaustion handling, expressed as a recursive promise chain instead of an async/await loop, restoring the original Promise<void> | undefined signature. sendTestFrameworkEvent keeps its boolean-success return (so the un-awaited caller at line 130 is unaffected). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…earing why Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
bsautomation
requested review from
kamal-kaur04 and
xxshubhamxx
and removed request for
a team
August 13, 2026 13:07
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
2 participants
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.
Merge into sdk_v9_pre_prod :by automationbs