Steps: 1. enable TP and ensure that the list has just been updated 2. take mozpub-track-digest256 out of disallow_completions 3. visit https://people.mozilla.org/~fmarier/tracking-test/ Expected: The list was just downloaded, all of the entries in it should be considered fresh and honored. Actual: The list appears to be stale and its entries are not honored because the gethash call fails. -1589647616[7fcca8883160]: Complete in mozpub-track-digest256 -1589647616[7fcca8883160]: Found a result in mozpub-track-digest256: complete. (Age: 86400s) -1589647616[7fcca8883160]: Found 1 results. -1589647616[7fcca8883160]: Found 1 results. -1589647616[7fcca8883160]: query took 0ms

From what we have in comment 1, somehow, the fresh value was not stored after doing update (although completion was stored). I still have no idea that, probably there's update failure or something like that. I tried to test several times manually, it seems ok, will try to make more tests and look closer.

Un-assigning for now since I don't think Thomas is actively working on it.

This may be fixed now that we are using the V4 negative cache for V2 lists too.

Actually, this is how the protocol is supposed to work according to Google. Full hashes in V2 still need to be confirmed via a gethash call before we are allowed to use them to block a website.