alinaboghiu
commented
7 months ago After chatting to @mxdvl we decided to create one generic surrogate key using the image id that will be associated with all fallback assets.
Steps
- [ ] 1. create new surrogate key with just the image id and associate with master all fallback assets
- [ ] 2. test manually that purging by this key removes all assets (in fastly)
- [ ] 3. update the purge tool to extract and use the image id for creating the purge request (frontend)
- [ ] 4. delete old surrogate keys
Mateusz: broken Fastly image cache busting? Despite gazillions of clicks on Clear yesterday and today, this https://i.guim.co.uk/img/media/76b38f30b2228a9db72ada8a39bd279b8b3db4f4/0_224_6720_4032/master/6720.jpg?width=620&dpr=2&s=none is still online.
David: As far as I can tell we are a victim of our own cleverness with the fallback mechanism. The cache purger has purged https://i.guim.co.uk/img/media/76b38f30b2228a9db72ada8a39bd279b8b3db4f4/0_224_6720_4032/master/6720.jpg (with all query params) and https://media.guim.co.uk/76b38f30b2228a9db72ada8a39bd279b8b3db4f4/0_224_6720_4032/master/6720.jpg
But it has not decached the non-master sizes (e.g. https://media.guim.co.uk/76b38f30b2228a9db72ada8a39bd279b8b3db4f4/0_224_6720_4032/1000.jpg). These are used when Fastly IO "fails", which includes returning a 404.
The fix would be to update the purge to include all versions in the media.guim.co.uk bucket.