Fix bug where requests with processors would not check disk cache for original image data #846
Conversation
… original image data `TaskFetchOriginalData` will now check the disk cache for the original image data before making a network request.
|
To fix #837. Please let me know if you'd like me to take a different approach. Thank you! |
|
Closing because I think I found a better solution. |
|
Reopening for now, realized the other approach has some drawbacks. |
|
The change that I've actually started using in my own app is to allow the pipeline delegate to provide unique custom keys for both the memory and disk caches. The setup I have is only disk cache the original image data (so key is just URL). The memory cache keys continue to be a function of both URL and The overall thought is that disk caching should only have unique keys for steps that are post-decode. |
|
Hey, thanks for raising the issue and for the extended details. I'm working on redesigning and simplifying the tasks for Nuke 13 – I'll address this as part of the rework. |
| @@ -29,6 +29,10 @@ final class TaskFetchOriginalData: AsyncPipelineTask<(Data, URLResponse?)>, @unc | |||
| return | |||
| } | |||
|
|
|||
| if let data = pipeline.cache.cachedData(for: makeSanitizedRequest()) { | |||
There was a problem hiding this comment.
Would this be better done in the TaskLoadData since the returnCacheDataDontLoad would block this.
There was a problem hiding this comment.
It looks like TaskLoadData only backs loadData calls so I don't think so.
I don't think returnCacheDataDontLoad blocking this is necessarily bad since one could argue returnCacheDataDontLoad should return an exact match in the cache for a given request, not cached original data that still needs to go through processors/thumbnail decoding. I don't feel super strongly about it though.
TaskFetchOriginalDatawill now check the disk cache for the original image data before making a network request.