Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f135b2556e900c616941bec46e8fcaa7f6f13ed1
https://github.com/WebKit/WebKit/commit/f135b2556e900c616941bec46e8fcaa7f6f13ed1
Author: Ryan Haddad <[email protected]>
Date: 2026-08-24 (Mon, 24 Aug 2026)
Changed paths:
M Tools/CISupport/ews-build/results_db.py
M Tools/CISupport/ews-build/steps.py
M Tools/CISupport/ews-build/steps_unittest.py
Log Message:
-----------
[ews] Safer C++ queues blame unchanged files when results-db has no result
for a test
https://bugs.webkit.org/show_bug.cgi?id=321829
rdar://185229829
Reviewed by Ryosuke Niwa.
The iOS Safer C++ queue reported Modules/webtransport/DatagramSink.cpp as a new
failing file on
PR 71664, which does not touch it. The build was based on 319210@main and the
expectations update
adding that file landed at 319223@main, so it did look new and check_results_db
asked the results
database whether the failure was pre-existing. The response was empty:
Response from results-db: {'does_result_match': False, 'raw_data': [],
'logs': ''}
An empty raw_data means the request succeeded but held no result for that test.
does_result_match
then fell through to the caller's default of 'PASS', compared it against
'FAIL', and declared the
file not pre-existing. Because a dict rather than None came back,
check_results_db treated that as
a successful verdict and skipped the tip-of-tree fallback, which would have
rebuilt without
the change and shown the failure was not caused by it.
Removing the `default` parameter collapses both "cannot answer" cases in
does_result_match into a
single None return, so the fallback in check_results_db always runs.
filter_results_using_results_db combined its two categories with `or`. Since
check_results_db
returns an empty set for a category with nothing to check, an unresolved
failures result was masked
by a non-None empty passes result, so it has to require both categories to
resolve.
* Tools/CISupport/ews-build/results_db.py:
(ResultsDatabase.does_result_match): Remove the `default` parameter, which had
no other production
caller, and return None for both a failed request and a response with no result
for the test.
* Tools/CISupport/ews-build/steps.py:
(FindUnexpectedStaticAnalyzerResults.filter_results_using_results_db): Require
both checks to resolve.
(FindUnexpectedStaticAnalyzerResults.check_results_db): Stop passing
default='PASS'. Log the test,
identifier and configuration that produced no answer, and note in stdio that a
build without the
change is being run.
* Tools/CISupport/ews-build/steps_unittest.py:
(TestFindUnexpectedStaticAnalyzerResults.configureResultsDatabase): Stub only
has_commit and
get_results so the real filtering runs, and restore the two methods other tests
in this class
replace on the class rather than with self.patch. Three tests cover escalation
on a missing result,
escalation when only the passes category is empty, and filtering of a genuine
pre-existing failure.
(TestResultsDatabaseFailureHandling.test_does_result_match_returns_none_when_there_is_no_result_for_the_test):
Replaces test_does_result_match_uses_default_on_empty_success, which asserted
the behavior fixed here.
Canonical link: https://commits.webkit.org/319710@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
