fix(context): keep reruns emitted before the closing failure/error tag

[mmatheson]

Summary

Fixes the case where a test that fails every retry is uploaded as a single run instead of one run per attempt — the failing-side counterpart to #1142 (TRUNK-18796).

Playwright's JUnit reporter (with includeRetries) emits a fail-all-retries test as a single <testcase> whose <rerunFailure>/<rerunError> attempts appear before the closing <failure>/<error>:

<testcase name="..." >
  <system-out>...</system-out>        <!-- attempt 0 only -->
  <rerunFailure .../>                 <!-- retry 1 -->
  <rerunFailure .../>                 <!-- retry 2 -->
  <failure .../>                      <!-- appended last -->
</testcase>

open_test_case starts each testcase as TestCaseStatus::Success, so each <rerunFailure> parsed before the <failure> is filed under flaky_runs (quick-junit routes reruns to flaky_runs while the status is Success). When the trailing <failure> arrives, set_test_case_status replaced the entire status enum with a fresh NonSuccess { reruns: [] }, discarding every earlier attempt. Result: the test collapses to a single run, and the retries survive only as concatenated text in the failure message.

The pass-on-retry (flaky) path was unaffected because a passing testcase has no closing <failure> to clobber the accumulated runs — which is exactly why pass-on-retry surfaced multiple runs but fail-all-retries did not.

Fix

In set_test_case_status, before overwriting a Success status, mem::take the accumulated flaky_runs and add_reruns them onto the new failure/error status, so each attempt still surfaces as its own run.

Test

Adds test_into_test_case_runs_emits_run_per_failing_rerun_playwright_order, which uses Playwright's real element order (system-out → rerunFailure… → failure). The existing test_into_test_case_runs_emits_run_per_failing_rerun passed only because it ordered <failure> before <rerunFailure> — the reverse of Playwright's actual output — which is why the regression slipped through.

• Before: 3 attempts → 1 run
• After: 3 attempts → 3 runs (all failures, per-retry output preserved)
• Full context parser suite green (15/15), including the existing Surface individual rerun attempts as separate test runs #1142 tests.

Notes

• Client-side only — the parser runs in the customer's CI and drops the attempts before upload, so ingestion/portal/monitors were never at fault. Bundles already uploaded by the buggy CLI stay one-run (the attempts were never captured).
• Verified against a real staging bundle: the internal.bin for a fail-all-retries run carried only the attempt-0 attachment in structured system_out (retries only in text), which pinpointed the dropped <rerunFailure> elements.

🤖 Generated during triage of the 0.15.0-beta.1 rerun report.

[trunk-io]

😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 98.38710% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 83.05%. Comparing base (7704b9d) to head (030e508).

Files with missing lines	Patch %	Lines
context/src/junit/parser.rs	98.38%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1143      +/-   ##
==========================================
+ Coverage   82.75%   83.05%   +0.29%     
==========================================
  Files          70       70              
  Lines       15788    15850      +62     
==========================================
+ Hits        13066    13164      +98     
+ Misses       2722     2686      -36     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trunk-staging-io]

     

Failed Test	Failure Summary	Logs
pending_quarantine_test should be quarantined when run with variant	A test marked as pending was expected to fail but unexpectedly passed.	Logs ↗︎
variant_quarantine_test should be quarantined when run with variant	A test expected the sum of 2 + 2 to be 5, but it was actually 4, indicating a failing assertion.	Logs ↗︎

View Full Report ↗︎ ⋅ Docs

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs