We've been working like maniacs to hit a deadline on this project, and hadn't had time to deploy the updated version of Assets that P&T's support quickly provided; although I did notice yesterday that the file I was testing this issue with had updated... apparently it just took a few days.

I strongly suspect this was a problem for us because we're using Cloudfront to serve these files, not plain vanilla S3.

There are several posts in the regular Stack Exchange site that address this issue; in order for Assets to handle this automatically, it looks like a special API call would need to be performed. Don't know if that's possible or not, but, at least there's a theoretical solution.

Barring that feature support:

• advise content creators to upload files with a version number in the filename instead of replacing them directly
• wait a few days for the new version to propigate on its own
• issue a cloudfront update manually via an API call or the AWS control panel

We've been working like maniacs to hit a deadline on this project, and hadn't had time to deploy the updated version of Assets that P&T's support quickly provided; although I did notice yesterday that the file I was testing this issue with had updated... apparently it just took a few days.

I strongly suspect this was a problem for us because we're using Cloudfront to serve these files, not plain vanilla S3.

There are several posts in the regular Stack Exchange site that address this issue; in order for Assets to handle this automatically, it looks like a special API call would need to be performed. Don't know if that's possible or not, but, at least there's a theoretical solution.

Barring that feature support:

• advise content creators to upload files with a version number in the filename instead of replacing them directly
• wait a few days for the new version to propigate on its own
• issue a cloudfront update manually via an API call or the AWS control panel