Closed Bug 1506697 Opened 10 months ago Closed 9 months ago
[wpt-sync] Sync PR 14024 - [wptserve] Eliminate race condition
Sync web-platform-tests PR 14024 into mozilla-central (this bug is closed when the sync is complete). PR: https://github.com/web-platform-tests/wpt/pull/14024 Details from upstream follow. Mike Pennisi <firstname.lastname@example.org> wrote: > [wptserve] Eliminate race condition > > This race condition was expressed during testing sessions where the > first test to use the Stash feature issued did so with multiple requests > made in parallel. > > --- > > The tests are brittle, but given the conditions we need to model, brittleness seems unavoidable. > > The server code hasn't changed recently, so it's a little surprising that a race condition should suddenly become an issue [in Taskcluster](https://github.com/web-platform-tests/wpt/issues/13989) and [in the results-collection project](https://github.com/web-platform-tests/results-collection/issues/625). Reviewing the status for each commit in `master` shows that [this intermittent error first surfaced on November 5](https://github.com/web-platform-tests/wpt/commits/master?after=7c568fdbd98ccdb92152c14521d3cc8c729a45a2+74). Guy Fawkes is the obvious suspect, but the trail's gone cold. I turned to more technical explanations. > > [The most recent Chromedriver release is version 2.43](https://chromedriver.storage.googleapis.com/index.html), and [that was published on October 16](https://chromedriver.storage.googleapis.com/2.43/notes.txt), ruling out a regression there. Chrome itself may have regressed, but I'm not set up to do any sort of bisecting, so I'm proceeding under the assumption that this is an issue in WPT. > > A small incongruity between the Buildbot and Taskcluster setup is useful here. Each system experiences the issue on a different "chunk" of WPT, but they define the segments in different terms. Buildbot uses 20 "chunks" containing tests of all types (failing on number 3) while Taskcluster uses 15 "chunks" for the testharness.js tests (failing on 13). We can narrow the set of suspect files by using the union of the following two lists: > > ./wpt run --list-tests --this-chunk 3 --total-chunks 20 chrome > ./wpt run --list-tests --this-chunk 13 --total chunks 15 --test-type testdriver -- chrome > > That returns 187 test files to consider. Feeding those files into `git log` shows that only one of them changed on that day: > > $ cat both.txt | xargs git log --after=2018-11-04 --before=2018-11-06 --oneline -- > 7e66d13 Ensure eval flag is properly transfered to context from CSPRO > > [`content-security-policy/script-src/eval-allowed-in-report-only-mode-and-sends-report.html` doesn't appear to be doing anything invalid.](https://github.com/web-platform-tests/wpt/blob/89188af97522b15cfe7ab6cc1c9cdb58007f0967/content-security-policy/script-src/eval-allowed-in-report-only-mode-and-sends-report.html) It does make parallel requests to a Stash-enabled endpoint, though (via [`checkReport.sub.js`](https://github.com/web-platform-tests/wpt/blob/89188af97522b15cfe7ab6cc1c9cdb58007f0967/content-security-policy/support/checkReport.sub.js)). The race condition fixed by this patch would only be expressed when the first test to use Stash did so via two parallel requests; my guess is that's uncommon but became true on November 5.
The PR was not expected to affect any tests, but the try push wasn't a success. Check the try results for infrastructure issues
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/378d0c633eae [wpt PR 14024] - [wptserve] Eliminate race condition, a=testonly
Result changes from PR not available.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/3545e39d77b5 [wpt PR 14024] - [wptserve] Eliminate race condition, a=testonly
You need to log in before you can comment on or make changes to this bug.