*sigh*  Thanks for catching this.

The latency experiment is an ongoing 1% holdback of SDCH requests to evaluate SDCH's performance.  It's only enabled for a specific URL (domain?) once a successful SDCH fetch has been done from that URL (domain?).  If you take a look at ~URLRequestHttpJob you'll see that RecordPacketStats is called with an argument indicating which group the job is in.

While I have no strong attachment to the latency experiment, it is active information that's being reported back via UMA, and if we're going to kill it, we should remove all code related to it and mark the relevant histograms obsolete.  Until that point, I think we should keep it going.  Given that your CL is a refactor CL, I think it needs to retain the information for the latency experiment, and this bug can track removing it at some point in the future.  

WDYT?

Ah, I see. That makes sense. Thanks for explaining how the code works! I will upload a new patch right away to add back sdch_manager->SetAllowLatencyExperiment(url_, true) part. I will leave this bug open so we can revisit this part of the code.

I am archiving this bug.
SDCH has been disabled in Chrome since M59. For more details please see  Issue 690070  and blink-dev@ thread https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nQl0ORHy7sw/HNpR96sqAgAJ.