This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+hiroshige

I incidentally talked with him about similar topics recently, and conclusion is basically we don't want to introduce negatice cache like things to the mem cache for simplicity. We assume disk cache still works and enough fast for an error path.

preload-only nagative cache may make sense.

In principal, I also don't want negative cache.

As for preloading, I think Issue 520179 is fixed (just being opened for a remaining test issue), and preloading is now much unlike "cache" (thanks to yhirano@), so I expect full-spec negative cache is not needed.

However, it might make sense to cache DecodedError resources, because they are successfully loaded in terms of fetch/loading, so in terms of Fetch spec, caching DecodedError resources are not negative cache.

Having DecodeError in Resource also causes a kind of layering violation: DecodeError is a concept in core/ (i.e. Image loading/decoding, or Font decoding), signalled from core layer, but causes MemoryCache eviction in platform layer/loading layer.
So removing DecodeError from Resource and caching it on MemoryCache might have benefit in terms of code health.

Are there factors that cause DecodeError flakily while loading (in terms of Fetch spec) completes successfully, i.e. due to flaky factors in the image layer?
If no, the negative impact exposed to users can be limited.

I first considered the case where fetch is terminated in the middle of loading due to network condition, but that cancellation is not catched by ResourceLoader/etc., and only cached by Image decoder as a DecodeError. (Hmm, but even this occurs, this is a problem to be fixed in the loading layer, because otherwise caching similar resources in non-ImageResource causes negative-cache-ish behavior of MemoryCache)

Interesting.

If we simply remove DecodeError concept from Resource, we need to keep loading even when we see a decode error. In other words, if we want to stop loading when we see a decode error AND cache it in MemoryCache, we need to say "we've cancelled loading due to an error but since it's persistent we'd cache it". I think that is DecodeError concept, and I'd argue it's a legitimate loading concept.

Separating DecodeError and LoadError further sounds good (e.g., ErrorOccurred() returns false for DecodeError).

hiroshige@, what do you think?

Talked with hiroshige@. We are leaning toward removing DecodeError from platform/loader, which means we won't store resources having DecodeError in the memory cache.