Open GHuygen opened 2 months ago
For our application, we have overriden PurgeHttpCacheListener
class (for various reason). The specific issue you're describing, we've solved by iterating over all existing GetCollection
operations of a resource class, hence invalidating all routes in which the specific entity is embedded.
See this code line and the loops around it: https://github.com/ecamp/ecamp3/blob/devel/api/src/HttpCache/PurgeHttpCacheListener.php#L181
By the way, the invalidation is not only needed for POST request, but also for DELETE requests and for updates as well, for example in case the $supplier
of a DeliveryDay
entity is modified.
I anyway wanted to check, which modifications we have done on our side which I could easily contribute back to api-platform. So I can try to to open a PR for this.
i think its related https://symfony-devs.slack.com/archives/C39FKU9AL/p1723577619039279
API Platform version(s) affected: 3.3.6
Description
Varnish cache is not released on a subresource. For example purposes, I use a
Supplier
and aDeliveryDay
entity.Supplier:
DeliveryDay:
How to reproduce
If you now use
/suppliers/{id}/delivery_days
, Varnish caches that response. If you then make a POST request to/delivery_days
, the cache from the collection route is not invalidated.Possible Solution
If you add a default
GetCollection
:It works, but then there is a route exposed that you don't really want.
So, I would suggest always adding a default cache tag to a collection. In this case, that would be
/delivery_days
(even when the route doesn't exist) and also add this tag to the invalidation service (even if the route doesn't exist).end word If I'm doing something that is not intended or missed some docs, please point me in the right direction. I would like to help resolve this issue by contributing, but I have never done that before. I would appreciate some help or guidance to get started.