Why cache tags from a webhook are not matching ones from X-Cache-Tags?

🆘 Support
1

Context:

  • 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?

2

Hi @clicker.lingo435,

Welcome to the Dato forums!

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.

3

Hello Roger and thank you for the reply!

I need more details about what exactly your allLabels query was

query {
    allLabels(locale: $locale) {
        code
        translation
    }
}

and which exact Label records & fields you updated.

item_types/bcDUx8J2QkKnfbNVXz27TQ/items/BR6W5k4JSKeDSpLDidWoCg

4

As you see I’m still experimenting with a very simple things trying to figure out if my expectations about DatoCMS caching are correct.

Thank you in advance for your help and let me know if you need more details :raised_hands:

5

Thank you @clicker.lingo435! Okay, so I found two issues:

  1. 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.
  2. I think your invalidation hook has some wayward quotes, probably from copying the JSON body? Corrected, it should look like:
    )j/9i*w #l((++ @z$j8\\>5][nc\\fo>5<!$.f8 @z)$y1gr$eq/sgm&\\z:*{dt svhvz@

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.

Does that explain it?

1 Like
6

That was it, thank you so much Roger! Dummy mistake from my side, forgot to publish :person_facepalming:

Is there maybe an auto-publish feature in DatoCMS?

1 Like
7

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.

1 Like
8

That works, thank you once again for the amazing support!

1 Like
9

You’re welcome! Glad we could figure it out :slight_smile: