FYI, this cache is chromeos only and nothing I can think of in extensions code proper has changed recently. I looked at the code in question and I'm not really sure why there's even a DCHECK here - it just means that we tried to insert something into the cache and found that there was already an entry for this extension id which was newer or the same version. That can certainly happen in certain circumstances, like if Omaha is in the process of rolling out a new version of an extension and one user got the new version and another user on the machine got served the old version. 

Anyhow, I'm working on a number of other high priority things right now and likely won't have time to look at this very soon, so I'm unassigning myself. I'd be happy to provide guidance if someone from chromeos wants to take a look at it. 

It seems like this would be pretty simple to bisect?

This is still a major nuisance when running on CrOS with dcheck_always_on = true (e.g. to look for other unexpected DCHECKs :) ).

This isn't a good use of a DCHECK since it's inside a condition that we handle. 

Scanning the code, it doesn't even look like an entirely invalid condition - the message is "Cache contains newer or the same version", and we log the same message as a WARNING in line 170.

I would propose logging a WARNING here, at least for now, and maybe filing and referencing a follow up issue.

I don't know why this DCHECK is reproduced reliably for me always with the same extension ID - "oedeeodfidgoollimchfdnbmhcpnklnd"; the cache initially contains version "0.76", and then a DCHECK is hit while trying to install version "0.74". Maybe it's because I'm testing a ToT build or because this extension was rolled back by Omaha.

Looking at the code, I actually think the DCHECK may be reasonable, because probably the relevant checkes should have been performed upper in the stack, before reaching LocalExtensionCache::OnCacheEntryInstalled (which works after the extension crx gets installed into the cache directory).

For instance, does anybody understand why is LocalExtensionCache::PutExtension calling FindExtension with the hash of the considered extension instead of empty string?
This makes the subsequent condition with NewerOrSame pretty much useless unless the cached version is equal to the considered version.
https://cs.chromium.org/chromium/src/chrome/browser/extensions/updater/local_extension_cache.cc?l=167

Strictly speaking, {D}CHECK and NOTREACHED should only be used for situations that should be logically impossible, e.g. unexpected input arguments to a function or return results from a function. We are also deprecating {D}CHECK << message.

That fact that it is not clear by inspection whether this failure case is invalid indicates that we shouldn't be using CHECK, we should LOG(ERROR) or LOG(FATAL). The fact that it is handled suggests LOG(ERROR) would be sufficient, with a bug filed to investigate the failure.

I've committed the patch to replace DCHECK with LOG(WARNING): http://crrev.com/2662863003.

Though this still leaves the question about the correctness of the logic in the LocalExtensionCache class (see e.g. comment 5 above).