Heya everyone,
If you are using graphql while also using memcache as your default cache backend, please introduce these lines to your settings:
$settings['cache']['bins']['graphql_ast'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_results'] = 'cache.backend.database';
This should let graphql use the database tables for caching purposes which seems to make the random issues go away.
I didn't find this fix by myself but got permission to share it to the community.
Hope this helps!
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.
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.
Updating the patch since I missed some changes on other files.
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,
Added an & false at the cache check for the asset file version checker.
esteban.arias → created an issue.
Changing the config implementation on the domain replacement to not use configEditable.
Implementing the suggested changes via a patch file to test this feature in combination with mod_proxy.
esteban.arias → created an issue.
Adding the patch which deals with this issue.
esteban.arias → created an issue. See original summary → .