New issue
Advanced search Search tips

Issue 911171 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

ConditionalCacheDeletionHelperBrowserTest.TimeAndURL is fragile

Project Member Reported by jam@chromium.org, Dec 3

Issue description

ConditionalCacheDeletionHelperBrowserTest.TimeAndURL depends on the timing of the cache, which isn't guaranteed.

To make it work with out of process networking, I converted it in https://chromium-review.googlesource.com/c/chromium/src/+/1357567. But the timing was different, and so it flaked twice on Win 7 Tests x64 main waterfall bot. I checked the other testers and didn't see any flakes. It was reverted, so I'm relanding and making it early-exit when network service is enabled.

Assigning to Martin as the original author of the test. We will be running the non-network service path on the bots for at least a few months, but this should be fixed before then.
 
Labels: Hotlist-Privacy
I think this can be fixed by rewriting the cache writes and reads the same way as we do it in

ClearSiteDataHandlerBrowserTest::CreateCacheEntry
ClearSiteDataHandlerBrowserTest::TestCacheEntry

That is, we can continue to use CacheUtil for in-process network stack (which is indeed timing-dependent and fragile, but AFAIU was inevitable, and in practice doesn't flake often). And then for network service, we'd use LoadBasicRequest() + LoadBasicRequest(ONLY_FROM_CACHE).
Yep, I had based the rewrite on ClearSiteDataHandlerBrowserTest and did as you suggested :) It was still flaky though.

There's the "TestTimeouts::tiny_timeout()" sleep, it's not guaranteed that the cache (in which every process) would be written.

I wonder if maybe we can add a ForTesting method on NetworkContext that reaches into the disk cache objects and forces them to flush?

Sign in to add a comment