"ExtensionWebRequestApiTest.WebRequestUnloadAfterRequest" is flaky |
|||||
Issue description"ExtensionWebRequestApiTest.WebRequestUnloadAfterRequest" 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=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyQgsSBUZsYWtlIjdFeHRlbnNpb25XZWJSZXF1ZXN0QXBpVGVzdC5XZWJSZXF1ZXN0VW5sb2FkQWZ0ZXJSZXF1ZXN0DA. 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
,
Jun 8 2016
The log [1] shows that the openTabWithSlowFrameAndRemoveTab, loadSlowTabAndClose and loadImageAndRemoveTab tests may time out. These tests load a main frame/child frame/image, wait until the response headers are received and then the tab is closed (and the request supposedly aborted as a result). The test framework stalls indefinitely if the expected events do not occur (=test timeout). This can happen in the following scenarios (=bugs): - the tabId & frameId & parentFrameId are missing (e.g. because the frame identifiers are not stored in the request, or because the frame data is not available in ExtensionApiFrameIdMap). - the request is somehow not aborted despite the tab being removed. I think that the first scenario is the most likely one, but I don't have a solution in mind yet. [1] https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_rel_ng/builds/224344/steps/browser_tests%20%28with%20patch%29%20on%20Ubuntu-12.04/logs/ExtensionWebRequestApiTest.WebRequestUnloadAfterRequest
,
Jun 10 2016
Detected 3 new flakes for test/step "ExtensionWebRequestApiTest.WebRequestUnloadAfterRequest". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyQgsSBUZsYWtlIjdFeHRlbnNpb25XZWJSZXF1ZXN0QXBpVGVzdC5XZWJSZXF1ZXN0VW5sb2FkQWZ0ZXJSZXF1ZXN0DA. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).
,
Jun 10 2016
Ping, any update?
,
Jun 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4918ee4223e07e1b0b51708bfed551f6036d3660 commit 4918ee4223e07e1b0b51708bfed551f6036d3660 Author: piman <piman@chromium.org> Date: Fri Jun 10 22:09:36 2016 Disable flaky test ExtensionWebRequestApiTest.WebRequestUnloadAfterRequest TBR=battre@chromium.org BUG=617865 Review-Url: https://codereview.chromium.org/2056103003 Cr-Commit-Position: refs/heads/master@{#399290} [modify] https://crrev.com/4918ee4223e07e1b0b51708bfed551f6036d3660/chrome/browser/extensions/api/web_request/web_request_apitest.cc
,
Jun 11 2016
Adding issue 522129 as a blocker, because I think that the problem is that the tabId/frameId/parentFrameId disappears "too soon" when a tab is closed. (cc devlin in case you have an idea on how to tackle this issue, see comment 2).
,
Jun 13 2016
,
Jun 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4918ee4223e07e1b0b51708bfed551f6036d3660 commit 4918ee4223e07e1b0b51708bfed551f6036d3660 Author: piman <piman@chromium.org> Date: Fri Jun 10 22:09:36 2016 Disable flaky test ExtensionWebRequestApiTest.WebRequestUnloadAfterRequest TBR=battre@chromium.org BUG=617865 Review-Url: https://codereview.chromium.org/2056103003 Cr-Commit-Position: refs/heads/master@{#399290} [modify] https://crrev.com/4918ee4223e07e1b0b51708bfed551f6036d3660/chrome/browser/extensions/api/web_request/web_request_apitest.cc |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by battre@chromium.org
, Jun 8 2016Owner: rob@robwu.nl
Status: Assigned (was: Untriaged)