Domain reliability is currently plugged in through ProfileIOData to the URLREquestContext. We'll need to hook it up some other way when the network service is enabled, since ProfileIOData does nothing meaningful in that case, and is going away eventually.
This presumably does not block enabled the network service on Canary.
Is there a schedule for when Network Service is going to Beta / Stable? I mentioned in #c1 that I don't think DR is a blocker for canarying the network service, but we will need to have it in place when the Network Service is in stable. We're still using DR to monitor traffic to Google domains, and want to run DR and NEL in parallel to verify NEL's coverage is equivalent to DR before we remove DR.
Also, are there example CLs or docs showing how to move other components off of ProfileIOData? If there's an easy pattern to follow I'm happy to do some of the work (modulo being OOO for bits of August).
Unfortunately, there's no playbook - lots of stuff hooked into ProfileIOData in very different ways. Some stuff could be moved completely into the network service. Other stuff could be moved to completely be in chrome/ or content/, and sit on top of the network service APIs. Other stuff just needs access to a new mojo API to query / modify data. Yet other stuff has to straddle the line, which also involves introducing new mojo APIs, but requests significant logic both within services/network and outside it in order to work.
Oh, and there's no fixed timeling for getting the network service in beta or stable - basically, once everything works. We'll have a better idea of when that will be once we get it on Canary, and it's good enough to stay on Canary.
I just took a quick look at this. The component itself looks like it depends on content (so can't be in network service) and is also tied closely to net/ (i.e. needs to be in network service).
It sounds like NEL will replace it. When is NEL going to stable?
NEL is going to stable experiment in M69 (crbug.com/799253). Assuming that doesn't encounter any regressions that we didn't catch in the Beta experiment (which is currently going), we'd go to stable a few weeks after that.
That said, we want to keep DR running for ~a quarter in parallel with NEL, so that we can verify that it has the same coverage before switching our internal monitoring pipelines over to the new data feed.
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.
All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Here's my plan: the content/ dependencies on this code are pretty minimal, and they seem easier to remove than the (naturally) tight net/ coupling. So I'll remove the content/ dependencies and then instantiate it in the network process if the network service is running.
the content deps are:
-networkconnectiontracker: I'll revert 4307dceb95b23b5075ca78b14790f8d039363f1d: https://chromium-review.googlesource.com/c/chromium/src/+/1334231
-remove content::IsOriginSecure since it's not necessary: https://chromium-review.googlesource.com/c/chromium/src/+/1334277
-the remaining content dependency is content::GetPermissionControllerw hich is checked before upload. That API was already asynchronous anyways, so I'll make it use network::mojom::NetworkContextClient to ask the browser. This is just like NetworkContextClient::OnCanSendReportingReports.
Comment 1 by dcreager@chromium.org
, Jun 15 2018