I'm unsure if this question belongs here or in Dragonfly upstream, but I'll try here.

I've uploaded hundreds of PDFs since I first created my Refinery app in 2015 (first 2.1.5, later upgraded to 4.0.3), and I've noticed this issue on and off. When I delete a Refinery::Resource in the CMS panel (say, to upload a new version of a document), the file is deleted from the filestore (I just use a local file store). However, the old direct link /system/resources/base64reallylongstring/old-document.pdf still works, so it's still being served from the Dragonfly cache.

Needless to say, I deleted the old document for a reason, and I would really like the link to go away from the internet (people could forward a link to the old document on email, for instance), and I also want to free up the space without needing to wait for a Redis LFU invalidation. I don't know much about the low level innards of the Rails cache handing, but shouldn't it invalidate the key when it's destroyed?

My site is extremely slow without caching due to some legacy architectural issues, so it's not an option to flush the entire cache when I delete a document.

Three questions:

1. Is this a bug?
2. If this behaviour is intentional, is there a good way to find the cache key that matches the deleted Refinery::Resource? Using the model id or something (file_uid?) to look it up and then expire that specific key?
3. Why does destroying the model (doing it from the CMS or the Rails console yields identical results) leave a .meta file behind?

Thanks in advance! If this is upstream behaviour, feel free to tell me, and I'll file an issue there instead.