Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9e098ca11b8f8de1ffc6bcd45ea2aabae15d7912
https://github.com/WebKit/WebKit/commit/9e098ca11b8f8de1ffc6bcd45ea2aabae15d7912
Author: Issac Roy <[email protected]>
Date: 2026-09-03 (Thu, 03 Sep 2026)
Changed paths:
M Tools/CISupport/ews-build/steps.py
M Tools/CISupport/ews-build/steps_unittest.py
Log Message:
-----------
[EWS] API EWS runs the whole retry ladder for an already-known flaky failure
https://bugs.webkit.org/show_bug.cgi?id=323311
<rdar://problem/186558544>
Reviewed by Aakash Jain.
When `run-api-tests` fails twice with the change, `ReRunAPITests.doOnFailure`
queues the revert, a rebuild and a clean-tree run, and only afterwards does
`AnalyzeAPITestsResults` ask the results database whether those failures were
flaky all along. `API-Tests-macOS-EWS` build 164902 spent 85 minutes on that
ladder before excusing a test the database records at a 98% pass rate.
Ask at the point the ladder would be queued instead. Both runs with the change
have reported their `BetweenStepsDirtyTree` evidence by then, so no evidence the
query depends on is lost. The first run still cannot ask: `run-api-tests` has no
`--treat-failing-as-flaky`, so it records one outcome per test, and a first-run
verdict would empty the failure list, pass the step, and prevent the rerun that
writes the only evidence API can produce.
Candidates are the failures both dirty runs share, taken from the same
`_filtered` properties `AnalyzeAPITestsResults` reads and falling back the same
way, so the two steps cannot disagree about what is excusable. When every
candidate has a verdict in `INCLUDED_FLAKY_VERDICTS` the build finishes green
through `force_build_success` and skips the revert, the rebuild, the clean-tree
run and the analyze step. One unexplained failure queues the ladder unchanged.
The early exit reports those candidates itself. `parse_and_set_failures` reports
only the symmetric difference of the two runs, and the intersection was reported
by `AnalyzeAPITestsResults`, which never runs on this path, so without a report
here the results-database rows for exactly the tests being excused would be
lost. The two reports remain disjoint, so nothing is written twice.
`flaky_new_failures_using_results_db` and `INCLUDED_FLAKY_VERDICTS` move to
`ResultsDBReportMixin`, which both callers now share.
* Tools/CISupport/ews-build/steps.py:
(ResultsDBReportMixin):
(ResultsDBReportMixin.flaky_new_failures_using_results_db):
(RunAPITests.__init__):
(RunAPITests.run):
(ReRunAPITests.failures_in_both_dirty_runs):
(ReRunAPITests):
(ReRunAPITests.doOnFailure):
(AnalyzeAPITestsResults):
(AnalyzeAPITestsResults.run):
(AnalyzeAPITestsResults.flaky_new_failures_using_results_db): Deleted.
* Tools/CISupport/ews-build/steps_unittest.py:
Canonical link: https://commits.webkit.org/320465@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
