Hugo appears to have stopped invalidating my Cloudfront cache

support
1

Not sure quite why, but Hugo was invalidating the cache quite successfully but is no longer doing so. What have I done wrong?

The output of hugo deploy says this:

Deploying to target “pbj-s3” (s3://xxxxxxxxx?region=us-west-1)
Identified 77 file(s) to upload, totaling 21 MB, and 0 file(s) to delete.
Success!

…and there is no invalidation message any more, nor an invalidation job listed in the AWS invalidation list.

I do have a few separate [[deployment.matchers]] sections in my config.toml, which I gather seems to be an issue sometimes, but unsure what the issue might be. Here’s the deployment section, suitably edited.

Is there anything that I can do to help debug this issue?

[deployment]

[[deployment.targets]]
name = “pbj-s3”
URL = “s3://xxxxxxxxxxx?region=us-west-1”
cloudFrontDistributionID = “EU4xxxxxxxxx”

[[deployment.matchers]]
pattern = “^.+\.(js|css|svg|ttf|woff|woff2|png|jpg|jpeg)$”
cacheControl = “max-age=31536000, no-transform, public”
gzip = false

[[deployment.matchers]]
pattern = “^sitemap\.xml$”
contentType = “application/xml”
gzip = false

[[deployment.matchers]]
pattern = “^.+\.(html|xml|json)$”
gzip = false

2

When did this start happening?
Which Hugo version are you using?

3

It started happening a couple of weeks ago, perhaps.

I’m using hugo v0.113.0+extended darwin/arm64

4

Did it begin before or after you installed v0. 113.0?

5

I can’t tell you, really (my Hugo upgrades are automatic). It was working fine on June 7, according to my invalidation logs, when I saw a Hugo-submitted invalidation call. It looks like Hugo’s upgrade to v0.113.0 was released on June 6, so may have happened on my system on June 8 or 9. I haven’t seen one since. So I would guess that it is related.

I have discovered that hugo deploy --invalidateCDN --verbose works fine. It looks perhaps like a regression of this bug perhaps?

Are there any logs I can submit to be helpful?

6

I will check, see deploy: --invalidateCDN, --maxDelete needs be explicitly set · Issue #11127 · gohugoio/hugo · GitHub

We did a massive consolidation of a very fragmented config setup in Hugo 0.112.0 where we unfortunately introduced some issues.

7

No, we have completely revamped this, so the above isn’t relevant anymore.

I checked the code, and we do have a passing end to end test that at least verifies that the configuration gets wired correctly.

Are you saying that adding the verbose flag makes the CDN invalidation happen? That’s a thing i don’t understand.

8

OK, I see what happens here. I will fix this, thanks for the report.

1 Like
9
1 Like
10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.