Only 1 model (Label) with code and translation fileds, very simple
When getting allLabels from Content Delivery API, I getting X-Cache-Tags: $o #)[br) "s3n:@ "l-r34 #e$3"0 "|e+'d )2pave; )2pat}%
When Iām updating a label item and saving it I would expect one of the tags from above to be present in Content Delivery API Cache Tags / Invalidate webhook payload, but itās not there. Tags there are totally different from ones above: )j/9i*w" #l((++" @z$j8\\>5][nc\\fo>5<!$.f8" @z)$y1gr$eq/sgm&\\z:*{dt" svhvz@
So, the invalidation logic doesnāt work because tags arenāt matching. Am I getting something wrong about the cache tags or is this a bug?
In order to more precisely troubleshoot this, I need more details about what exactly your allLabels query was, and which exact Label records & fields you updated. Could you please provide the context?
Looking through your project, it seems like you made several updates and a few invalidation webhooks were sent (as you can see in the Webhooks Activity log in your Project Settings), each with a few different cache tags. Decoding those cache tags (with our internal tools), it does look like it was invalidating the collection (which should in turn affect an allLabels query too).
What specifically did you test updating? May I try replicating those exact same steps in your project (and re-adding the invalidation webhook) so I can better trace what is happening?
Without more details, my best guess is that maybe the webhook itself wasnāt set up until after some of the initial updates (which wouldāve caused the proper invalidations), and your subsequently tested updates maybe didnāt update anything inside your allLabels query, so the system didnāt think it needed to be invalidated again?
Each piecemeal cache tag tries to invalidate only what it needs to. The system analyzes your exact updates, not the whole record or collection, and only generates the cache tags it needs to ā i.e., it wonāt necessarily invalidate an allLabels query if you updated something that wasnāt in the query.
In your allLabels query, you probably werenāt requesting drafts, so you were only getting published records. When you clicked āSaveā, you saved a new draft, but because you didnāt publish it, the GraphQL query wasnāt affected. Either you could publish the record, or add the X-Include-Drafts: true header to also get drafts in the CDA.
I think your invalidation hook has some wayward quotes, probably from copying the JSON body? Corrected, it should look like:
Once you take both into account, the #l((++ (for the labels model) and )j/9i*w (for the specific record) should now match up, indicating a successful cache tag hit.
Sort of! If you edit the model settings (where you change its name and presentation settings and such), you can turn off the draft/published system for that model altogether. (Itās a per-model toggle).
When that system is off, āsavingā a record will immediately publish it, and there will be no intermediate ādraftā status.