It looks like extracting test results is frequently taking 10+ minutes, adding up to a lot when we often run tests twice. My build: https://ews-build.webkit.org/#/builders/73/builds/22639 Others picked at random: https://ews-build.webkit.org/#/builders/73/builds/22631 (17 minutes!) https://ews-build.webkit.org/#/builders/73/builds/22619
Looks like we have 35K files in the archive, most of them stderr output of this kind: 2022-12-15 18:20:33.500 DumpRenderTree[27762:191348898] nil host used in call to allowsSpecificHTTPSCertificateForHost 2022-12-15 18:20:33.500 DumpRenderTree[27762:191348898] nil host used in call to allowsAnyHTTPSCertificateForHost: Not sure if something changed recently, but we should definitely fix this.
What's also weird is that these are not in results.html. Are we just failing to clean the results directory between runs?
No - checking the dates of -stderr.txt files on a bot, that's not what is happening, they are all recent.
I also was able to reproduce this problem very easily on a local build. I'm going to see if I can figure out the cause of the problem with code inspection, but we might consider attempting to bisect.
From testing locally, looks like there are 2 problems: 1) It's somehow possible for us to get empty allowed hosts or local host aliases. I still haven't figured out _how_ that's possible, though, because according to the code, it shouldn't be possible. 2) Clearly out our database caches is racy because these caches are shared between all workers. This race seems so obvious, though, that I'm unclear what I'm missing.
Not convinced https://bugs.webkit.org/show_bug.cgi?id=249614 is problem, but it does seem to be a problem.
Turns out that these were a known bug fixed in macOS Ventura, so we should just filter out output on older OSes: > 2022-12-15 18:20:33.500 DumpRenderTree[27762:191348898] nil host used in call to allowsSpecificHTTPSCertificateForHost > 2022-12-15 18:20:33.500 DumpRenderTree[27762:191348898] nil host used in call to allowsAnyHTTPSCertificateForHost: I didn't check if this resolves enough of the spurious logs.
<rdar://problem/103657108>