"external/wpt/background-fetch/fetch.https.window.html" is flaky |
|||||
Issue description"external/wpt/background-fetch/fetch.https.window.html" is flaky. This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label. We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyQAsSBUZsYWtlIjVleHRlcm5hbC93cHQvYmFja2dyb3VuZC1mZXRjaC9mZXRjaC5odHRwcy53aW5kb3cuaHRtbAw. Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
,
Jul 26
peter@ - PTAL. Test is flaking repeatedly over multiple days with timeouts. Example failure: https://test-results.appspot.com/data/layout_results/mac_chromium_rel_ng/102514/layout-test-results/results.html
,
Jul 27
,
Jul 27
Thanks!
Measuring the test, what I'm seeing is:
@ 920ms - global scope being executed
@ 930ms (=10ms) - the promise_test() being executed
@ 1120ms (=190ms) - Service Worker registered, activated
@ 1134ms (=14ms) - BGFetchManager.fetch() called and acknowledged
@ 6218ms (=5084ms) - test finished
This means that it's taking 5 seconds for a trivial, ~20 byte fetch to complete and reach the Service Worker, which is way too long. In our C++ code this roughly maps to:
@ 0.628s - BackgroundFetchContext::StartFetch()
@ 0.629s - BackgroundFetchContext::CreateController()
- BackgroundFetchDelegate::CreateDownloadJob
@ 0.633s - BackgroundFetchJobController::StartRequest()
@ 5.643s - BackgroundFetchJobController::DidStartRequest()
@ 5.657s - BackgroundFetchJobController::DidUpdateRequest()
@ 5.658s - BackgroundFetchJobController::DidCompleteRequest()
@ 5.675s - BackgroundFetchContext::DidFinishJob()
@ 5.676s - BackgroundFetchContext::DidMarkForDeletion()
@ 5.681s - BackgroundFetchContext::DidGetSettledFetches()
@ 5.723s - BackgroundFetchContext::CleanupRegistration()
The call to BackgroundFetchDelegateProxy::StartRequest() takes over five seconds to be acknowledged.
,
Jul 27
All the waiting time is being spent between DownloadService::StartDownload() and them calling our download::Client::OnDownloadStarted(), so debugging moves to their component..
,
Jul 27
We're hitting the start-up delay imposed by the DeviceStatusListener. It's set to five seconds (kDefaultNetworkStartupDelay) by default in the DownloadService configuration, and intended to give the network stack a chance to start. Let's see if we can set it to zero :).
,
Jul 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/de2620b0afccf93dbca09ee3bb095c0ca414de9c commit de2620b0afccf93dbca09ee3bb095c0ca414de9c Author: Peter Beverloo <peter@chromium.org> Date: Mon Jul 30 12:20:25 2018 Force-enable the DownloadService when running layout tests We have a strict dependency, so the base::Feature entry should be disabled. In addition, set the network start-up delay to zero, as there is no need to throttle network activity in testing scenarios. Bug: 866116 Change-Id: I5d2d22f20601824d09c7fd22233406dca7774268 Reviewed-on: https://chromium-review.googlesource.com/1153048 Commit-Queue: Peter Beverloo <peter@chromium.org> Reviewed-by: Rayan Kanso <rayankans@chromium.org> Cr-Commit-Position: refs/heads/master@{#579019} [modify] https://crrev.com/de2620b0afccf93dbca09ee3bb095c0ca414de9c/content/shell/browser/layout_test/layout_test_background_fetch_delegate.cc
,
Jul 30
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by chromium...@appspot.gserviceaccount.com
, Jul 24