Looks like a flake, and it hasn't happened again that I can see. I'm not sure what would cause it. Maybe another case similar to  issue 738442 .

Now there's also a case of the first request succeeding and the second request failing. That one is probably caused by the pref not getting written in time.

No need to R-V-G this.

 Issue 741814  has been merged into this issue.

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

commit db5ca9b349de8a50712af2356f1748941b37da29
Author: Miriam Gershenson <mgersh@chromium.org>
Date: Thu Jul 13 16:22:30 2017

Add delay to wait for prefs in testHostCachePersistence

I'm not sure if this will fix the flake, since I can't repro locally,
but it seems plausible.

BUG= 740207 

Change-Id: Icd423f4221b460bedc31299ec8a69d002d3a9db1
Reviewed-on: https://chromium-review.googlesource.com/570358
Reviewed-by: Misha Efimov <mef@chromium.org>
Commit-Queue: Miriam Gershenson <mgersh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486407}
[modify] https://crrev.com/db5ca9b349de8a50712af2356f1748941b37da29/components/cronet/android/test/javatests/src/org/chromium/net/ExperimentalOptionsTest.java

Issue 742427 has been merged into this issue.

Doesn't look like it's fixed? 
Here's a flake after the CL:
https://build.chromium.org/p/chromium.android/builders/Android%20Cronet%20KitKat%20Builder/builds/2709

This is still flaking on https://uberchromegw.corp.google.com/i/chromium.android/builders/Android%20Cronet%20ARMv6%20Builder

This bug turned out to be weirder than I thought. It's actually three bugs:

1. Given current Cronet API behavior, my test should set either HTTP_CACHE_DISK or HTTP_CACHE_IN_MEMORY, but doesn't. I'll fix that on Monday because it's getting late and no one else is around to lgtm anyway.

2. There's a race condition between creation of the CronetURLRequestAdapter and initialization of the CronetURLRequestContextAdapter on the network thread that causes cache to be enabled when it shouldn't be if a UrlRequest is created immediately after building the CronetEngine. This is why the test only failed 1% of the time instead of consistently failing. When I put in a delay, it started consistently failing.

3. This API behavior is weird. Why does HTTP_CACHE_IN_MEMORY enable DNS cache but HTTP_CACHE_DISK_NO_HTTP doesn't? What is HTTP_CACHE_DISK_NO_HTTP even for? I read our documentation and it doesn't really say. Unfortunately this involves behavior way deep in the net stack and might be tricky to change.

I'll keep this bug for (1) and make separate bugs for (2) and (3).

Can I first disable this test or set it as flaky?

I've got some background history behind HTTP_CACHE_DISK_NO_HTTP. 

It exists as some of net stack metadata, for example QUIC Server Info used for 0-rtt, was stored in disk cache. This requires HTTP cache to be enabled and configured.

At the same time many apps that use Cronet don't want HTTP responses to be cached as they use app-specific caches at higher levels. 

This is addressed by HTTP_CACHE_DISK_NO_HTTP mode, where metadata is stored in disk cache, but actual http response data is not.

The underlying implementation of HTTP_CACHE_DISK_NO_HTTP implicitly adds net::LOAD_DISABLE_CACHE flag to default load flags: https://cs.chromium.org/chromium/src/components/cronet/android/cronet_url_request_context_adapter.cc?rcl=f4e2fd0da1b5be8802440ada0bbff3aa1ea985af&l=755

It is possible (needs to be confirmed) that setting this flag also disables DNS Cache, which is not desirable.

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

commit 6ad408ef384a021964d7968abd0e18cb8b902d77
Author: Miriam Gershenson <mgersh@chromium.org>
Date: Mon Jul 17 16:40:28 2017

Enable disk cache in testHostCachePersistence

This fixes the flake.

BUG= 740207 

Change-Id: I68fd807c8bb9effc1c0e9e15e744146c4b1f15c0
Reviewed-on: https://chromium-review.googlesource.com/574571
Reviewed-by: Misha Efimov <mef@chromium.org>
Commit-Queue: Miriam Gershenson <mgersh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487113}
[modify] https://crrev.com/6ad408ef384a021964d7968abd0e18cb8b902d77/components/cronet/android/test/javatests/src/org/chromium/net/ExperimentalOptionsTest.java