New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 726364 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 728060



Sign in to add a comment

Some ReloadCacheControlBrowserTest tests are flaky

Project Member Reported by roc...@chromium.org, May 25 2017

Issue description

Flake appeared recently on https://uberchromegw.corp.google.com/i/chromium.win/builders/Win%207%20Tests%20x64%20%281%29

First instance of failure I can see is https://uberchromegw.corp.google.com/i/chromium.win/builders/Win%207%20Tests%20x64%20%281%29/builds/24572

I was unable to locate a reasonably suspicious culprit CL in the likely regression range.
 

Comment 1 by mmenke@chromium.org, May 25 2017

Components: UI>Browser>Navigation
Cc: toyoshim@chromium.org
+toyoshim author of the test

Comment 3 by mmenke@chromium.org, May 25 2017

We aren't using PlzNavigate on the bots now, are we?

Comment 4 by nasko@chromium.org, May 25 2017

No, PlzNavigate is not on by default. It runs on bots, but each step is clearly named with a prefix of "browser_side_navigation". So failing just "content_browsertests" implies no PlzNavigate.

Comment 5 by guidou@chromium.org, May 26 2017

Labels: -Sheriff-Chromium
Status: Available (was: Untriaged)
Still showing up, though the test might need to be rewritten and this is WAI. I don't believe that there are any guarantees that requests open on the client (Chrome) will hit the test server in the same order as they are open (due to network latency/etc).
Owner: toyoshim@chromium.org
Status: Assigned (was: Available)
Right, the test mistakenly relies on a behavior that are not ensured.
I will fix the test.
Blockedon: 728060
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=ReloadCacheControlBrowserTest

ReloadCacheControlBrowserTest.NavigateToSame
ReloadCacheControlBrowserTest.NormalReload
ReloadCacheControlBrowserTest.BypassingReload (I filed another bug for this)

are flaky.
Status: Started (was: Assigned)
Project Member

Comment 10 by bugdroid1@chromium.org, Jun 1 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf698306c4a097eb809fcf403c12e66358396747

commit bf698306c4a097eb809fcf403c12e66358396747
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Thu Jun 01 05:24:10 2017

Rewrite ReloadCacheControlBrowserTest

Original tests are flaky because they rely on unwarranted order how
Chrome issues network requests.

New test does not check expectations in an expected order, but
just check if cache control flag is expected one for each resource.

BUG= 726364 ,  728060 

Change-Id: Idb2367a259f22779581ac59b0c0017cd1256f3b9
Reviewed-on: https://chromium-review.googlesource.com/519283
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#476200}
[modify] https://crrev.com/bf698306c4a097eb809fcf403c12e66358396747/content/browser/loader/reload_cache_control_browsertest.cc

Status: Fixed (was: Started)

Sign in to add a comment