Problem/Motivation

We sometimes get the following error:
Your request contains a caller reference that was used for a previous invalidation batch for the same distribution.

purger_cloudfront_xxx: Aws\CloudFront\Exception\CloudFrontException: Error executing "CreateInvalidation" on "https://cloudfrontxxx/invalidation"; AWS HTTP error: Client error: `POST https://cloudfrontxxx/invalidation` resulted in a `400 Bad Request` response: <?xml version="1.0"?> <ErrorResponse xmlns="http://cloudfront.amazonaws.com/doc/2020-05-31/"><Error><Type>Sender</Type>< (truncated...) InvalidArgument (client): Your request contains a caller reference that was used for a previous invalidation batch for the same distribution. [...]

Proposed resolution

Change the caller reference to be more accurate. Like hash of paths to invalidate + timestamp.

Issue fork cloudfront_purger-3304477

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

eyilmaz created an issue. See original summary.

eyilmaz opened merge request !1

eyilmaz’s picture

eyilmaz
Primary language German
Location Berlin, Germany
commented
Status: Active » Needs review

MR opened.

kim.pepper’s picture

kim.pepper
Primary language English
Location 🏄‍♂️🇦🇺Sydney, Australia
commented
Status: Needs review » Postponed (maintainer needs more info)

I believe the paths are already taken into account.

I am open to other ideas about what the caller reference should be, but it might be worth reading the documentation first. https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Invalidat...

eyilmaz’s picture

eyilmaz
Primary language German
Location Berlin, Germany
commented

From the docs:

If CallerReference is a value you already sent in a previous invalidation batch request but the content of any Path is different from the original request, CloudFront returns an InvalidationBatchAlreadyExists error.

So if you send the same second another request, this is the case.

kim.pepper’s picture

kim.pepper
Primary language English
Location 🏄‍♂️🇦🇺Sydney, Australia
commented

So we could just use microtime()?

eyilmaz’s picture

eyilmaz
Primary language German
Location Berlin, Germany
commented

That would be an option, however it does not guarantee the CallerReference to be unique. In theory, if you have parallel invalidations running, one of them could fail even using microtime().

kim.pepper’s picture

kim.pepper
Primary language English
Location 🏄‍♂️🇦🇺Sydney, Australia
commented

What about a random number then?

superrn’s picture

superrn commented

We are seeing this often on a new project that we are deploying with this purger. Is there a proper fix for this?