Issue metadata
Sign in to add a comment
|
NetworkContextConfigurationBrowserTest.DiskCache is flaky |
||||||||||||||||||||||||
Issue descriptionhttps://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=ProfileMainNetworkContext%2FNetworkContextConfigurationBrowserTest.DiskCache%2F2 shows some flakiness. Although the bot runs eventually go green, this test oftentimes need retries to pass. [ RUN ] ProfileMainNetworkContext/NetworkContextConfigurationBrowserTest.DiskCache/2 [3532:4180:0423/122746.329:ERROR:install_util.cc(589)] Unable to create registry key HKLM\SOFTWARE\Policies\Chromium for reading result=2 [3532:3068:0423/122746.390:WARNING:discovery_network_list_win.cc(195)] Failed to open Wlan client handle: 1062 [3532:4180:0423/122746.397:WARNING:chrome_browser_main_win.cc(630)] Command line too long for RegisterApplicationRestart: --brave-new-test-launcher --cfi-diag=0 --gtest_also_run_disabled_tests --gtest_filter=ProfileMainNetworkContext/NetworkContextConfigurationBrowserTest.DiskCache/2 --single_process --test-launcher-bot-mode --test-launcher-output="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir6556_4543\results6556_25456\test_results.xml" --test-launcher-summary-output="e:\b\swarm_slave\w\iozhivzu\output.json" --user-data-dir="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir6556_4543\d6556_25043" --disable-offline-auto-reload --no-first-run --no-default-browser-check --enable-logging=stderr --disable-default-apps --wm-window-animations-disabled --disable-component-update --test-type=browser --force-color-profile=srgb --disable-zero-browsers-open-for-tests --ipc-connection-timeout=30 --allow-file-access-from-files --dom-automation --log-gpu-control-list-decisions --disable-backgrounding-occluded-windows --disable-gl-drawing-for-tests --override-use-software-gl-for-tests --force-color-profile=srgb --disable-compositor-ukm-for-tests --enable-features=NetworkService,TestFeatureForBrowserTest1 --disable-features=NetworkPrediction,TestFeatureForBrowserTest2 --flag-switches-begin --flag-switches-end --restore-last-session about:blank ../../chrome/browser/net/network_context_configuration_browsertest.cc(574): error: Expected equality of these values: original_response Which is: "de68d521-b7ea-4d4f-8fbf-1cc61acd060b" response_body Which is: "" Stack trace: Backtrace: testing::internal::UnitTestImpl::CurrentOsStackTraceExceptTop [0x00000001400EDE77+87] testing::internal::AssertHelper::operator= [0x00000001400ED9FE+78] std::unique_ptr<net::test_server::ControllableHttpResponse,std::default_delete<net::test_server::ControllableHttpResponse> >::reset [0x000000013F541E9E+9550] content::BrowserTestBase::ProxyRunTestOnMainThreadLoop [0x0000000141B3972D+477]
,
Apr 24 2018
I think I'm going to disable the the crash test in the disk cache case - more generally, I think we may have to disable *all* crash tests that write data to disk, unless there's a way to flush that data (For checking on-disk cookie storage, there are APIs to delete cookies that wait until the store is flushed, not sure about other things)
,
Apr 24 2018
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eabded07b6d8c73e8c11b7a2894c3b5ff98d781a commit eabded07b6d8c73e8c11b7a2894c3b5ff98d781a Author: Matt Menke <mmenke@chromium.org> Date: Tue Apr 24 17:10:41 2018 Add workaround to NetworkContextConfigurationBrowserTest.DiskCache. When the network service is restarted, the disk cache entry may be not be recovered, for reasons that aren't completely clear (corruption? disk contention?), which causes the test to flake. This CL modifies the test to not fail in that case. Bug: 836073 Change-Id: I3eedeceae6145b1d386749125c8232d552be8308 Reviewed-on: https://chromium-review.googlesource.com/1025646 Commit-Queue: Matt Menke <mmenke@chromium.org> Reviewed-by: Maks Orlovich <morlovich@chromium.org> Cr-Commit-Position: refs/heads/master@{#553177} [modify] https://crrev.com/eabded07b6d8c73e8c11b7a2894c3b5ff98d781a/chrome/browser/net/network_context_configuration_browsertest.cc
,
Apr 24 2018
This should (hopefully...) be fixed.
,
Apr 24 2018
Re #c1: I agree with your analysis, and this issue seems to be related to issue 792255 I encountered before. Anyway thanks for adding the workaround! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mmenke@chromium.org
, Apr 24 2018Components: -Internals>Network Internals>Network>Cache Internals>Services>Network
The "/2" is the case where we crash the network process and then restart it. The in-process ("/0") and out of process ("/1") versions do not look to be flaky, and it seems like the flake may just be on windows? Note that the way the tests work is that we start Chrome, start the network process, send a dummy request (Not the one we're testing caching on), wait for a response, and then crash the network service. The we restart the network service, and test a previously cached result (From an earlier execution of PRE_DiskCache). Two possible explanations (Assuming the /0 and /1 versions are indeed not flaky): * The cache is not recovered after the crash (Or not recovered immediately, at least). * The test is sometimes failing to re-open the cache file because the OS has yet to fully clean up the crashed process. morlovich: Any thoughts?