DAM Asset Download not updating asset versions

Added an & false at the cache check for the asset file version checker.

I cannot tell whether the solution proposed for fixing is good or bad, but I share my concerns about how caching API responses was implemented back then. For example, I can't recall any evidence of how these cache objects got invalidated. During testing on my local instance, I regularly hit $ drush cr to get the results from API calls as expected. It can be seen as my limitation, but I believe the entire caching logic of the module could be revised and eventually improved if time allows. One possible option can be to rely on Widen's recently introduced Webhooks and initiating purging our caches based upon receiving a call from their side.

Hello @baluertl,

The problem here is that there are also cron jobs checking the file versions so if a cron runs after a file got updated and the cache was not refreshed beforehand, then the file gets stuck in the previous version and assumes that it already checked for version updates.

I am helping one project which is facing issues with the media sync as well and it was noticed that when the metadata gets updated via cron jobs, it doesn't load the new version of the file into the local file field.

I am adding another patch which introduces the metadata update step to the processItem so that the file gets updated when it's queued for an update by the system.

Thank you for your help with this issue! I do agree that there can be a better way of caching these requests or keeping the feature for customers who aren't relying on the asset versions feature entirely.

Regards,

Updating the patch since I missed some changes on other files.

After further testing it was identified that while the asset does get updated once when the changes are detected, a further update does not synchronize the files on the media entity.

Currently researching the processItem function from the QueueWorker to figure out why the asset gets updated once and not every time.

Will post a patch promptly with a hotfix if any is found.

The logic has been simplified on a newer patch which does the following:

1. The cache mechanism for the version check remains invalidated.
2. The metadata function which downloads the file will download the file again even if the media entity already exists.
3. The cron job keeps using the metadata load function to get the file.

While testing I did notice that the cron is not built to check all the files for new versions but rather goes over the items which were detected as having updates pending. This means that I was able to get the new media file downloaded by using the "Check for Updates" button on the media item and then running the cron to download the new file.

I did notice that the media_acquiadam does have configurations to check the media for updates on every cron, but this module stopped being maintained last year: https://www.drupal.org/project/media_acquiadam → .

It may be worth exploring implementing auto versioning checks on the cron job but this could also have a big impact on sites that have a lot of media.

The MR incorporates some of esteban's suggestions in the patch and removes the version specific caching, which does appear to be breaking the updated versions. Fixed!

Automatically closed - issue fixed for 2 weeks with no activity.