Can mmenke@ and tbansal@ weigh in with more details about the rough edges mentioned in  issue 721403 ? I'm running Chrome with the Network Service enabled and have not seen any crashes related to net::URLFetcher failing to load configuration. I can add in code to make sure that DRP is being disabled but I want to make sure I can reproduce the things we are worried about.

It directly dereferences a number of network objects (NQE, NetLog, not sure what others), and crashes if they don't exist - we make an NQE for the dummy in-process URLRequestContext solely so it doesn't crash.  None of the hard edges I was thinking of were related to URLFetchers.

I think there's a question of whether we want to go to Canary while we still have to create the legacy in-process URLRequestContext not to crash or not.  I'd say we don't, since it means something is likely broken.

@Matt: are you specifically talking about DRP dereferencing URLRequestContext? DRP isn't needed on Windows canary. Is there a single choke point we can use to disable that feature?

I'm not familiar enough with it to know if there's a single choke point we can disable.  I am talking about it dereferencing the URLREquestContext.

jam@, finding that one choke point at which we can disable this feature is the work being tracked by this issue. What I was looking for was figuring out how to actually hit the issues that mmenke@ and tbansal@ were hinting at because otherwise I can't be as confident that I've successfully disabled enough functionality to avoid them.

To be clear, DRP is in use by some Windows canary users. I hope you don't intend on keeping DRP disabled for very long.

DRP hard-crashes on Windows when NQE is nullptr.

To elaborate a little - we have code listening to the NQE on Windows, in a bunch of locations (I think 3 or 4?  Though one is just for net-internals, which we don't care about).  So objects are being created, and presumably they're doing something.

If an audit of all callsites indicates they don't matter on Canary, we can reduce the priority of this bug, and mark it non-Canary blocking.

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

commit f2b6eadfc3999a6703f5b65701e9d0137fdcdebe
Author: Clark DuVall <cduvall@chromium.org>
Date: Wed Aug 15 21:08:41 2018

Disable data reduction proxy when network service is enabled

This also prevents any crashes if we remove the legacy URLRequestContext
getter in the network service.

Bug:  855621 
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: Ie14b64b803c8563ecae355dc220c9e56d11b4e7b
Reviewed-on: https://chromium-review.googlesource.com/1176117
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Tarun Bansal <tbansal@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583388}
[modify] https://crrev.com/f2b6eadfc3999a6703f5b65701e9d0137fdcdebe/chrome/browser/profiles/profile_impl_io_data.cc
[modify] https://crrev.com/f2b6eadfc3999a6703f5b65701e9d0137fdcdebe/components/data_reduction_proxy/core/browser/data_reduction_proxy_config_service_client.cc
[modify] https://crrev.com/f2b6eadfc3999a6703f5b65701e9d0137fdcdebe/components/data_reduction_proxy/core/browser/data_reduction_proxy_io_data.cc
[modify] https://crrev.com/f2b6eadfc3999a6703f5b65701e9d0137fdcdebe/components/data_reduction_proxy/core/browser/data_reduction_proxy_settings.cc
[modify] https://crrev.com/f2b6eadfc3999a6703f5b65701e9d0137fdcdebe/components/data_reduction_proxy/core/browser/warmup_url_fetcher.cc
[modify] https://crrev.com/f2b6eadfc3999a6703f5b65701e9d0137fdcdebe/testing/buildbot/filters/mojo.fyi.network_browser_tests.filter