Problem/Motivation
Facing a DAM document versioning issue in Drupal. When an asset has multiple versions in Acquia DAM, switching from an old version to a new version (including uploading a new file version and finalizing it) does not update the corresponding Drupal media entity. Drupal continues to display the old version even after running cron multiple times from Acquia Cloud IDE.
This behavior is reproducible only on module versions greater than 1.1.9. On version 1.1.9, uploading a new DAM document version correctly updates Drupal after cron runs.
Based on the changelog for versions 1.1.9 → 1.1.10, there were notable changes related to:
- Finalized version handling fixes
- Updates to
AssetUpdater::queueAssets()involvingfinalized-version - New Drush commands for resolver updates and redownload workflow
- New caching behavior in
ImageStyleHelper - Support for private file system (which can alter download paths)
These changes may have introduced a regression preventing Drupal from detecting and pulling the latest finalized DAM version.
Steps to reproduce
- Install
acquia_damversion 1.1.10, 1.1.11, or 1.1.12. - In Acquia DAM, create a document with multiple versions.
- Upload a new document version and mark it as finalized.
- In Drupal, run cron multiple times using Acquia Cloud IDE.
- Open the corresponding media entity in Drupal.
- Expected: Drupal should display the latest finalized version.
- Actual: Drupal still shows the previous (older) version of the document.
As a control test, repeat the same steps on version 1.1.9: Drupal correctly shows the latest version, indicating a regression introduced in versions ≥ 1.1.10.
Proposed resolution
- Review changes made in 1.1.10 related to
finalized-versioninsideAssetUpdater::queueAssets(). - Verify sync logic for determining whether an updated DAM version should trigger a redownload.
- Inspect Drush-based resolver update workflow added in 1.1.10 to ensure normal cron sync does not depend solely on manual Drush commands.
- Check whether ImageStyleHelper caching prevents Drupal from showing the latest file version.
- Confirm that the private file system changes did not alter file paths or update triggers.
- Create a fix that restores the pre-1.1.9 behavior where finalized versions always sync automatically through cron.
Remaining tasks
- Add debugging logs to DAM asset update process.
- Verify queue behavior around the
finalized-versionmetadata. - Compare stored metadata vs. DAM API response for updated assets.
- Add automated test for “upload new DAM version → finalize → cron → updated in Drupal”.
- Prepare a patch/MR fixing version detection and sync logic.
- Test patch against versions 1.1.10, 1.1.11, and 1.1.12.
User interface changes
No UI changes required. UI will automatically show the latest version once backend sync logic is fixed.
API changes
No public API changes expected. Internal resolver and sync logic may need updates.
Data model changes
No data schema changes required. Validation may be needed on stored:
- Finalized version number
- Local file URI
- Private/public file system paths
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3577492-reversioning-asset-not-syncing.patch | 1.86 KB | chakkche |
| #2 | DAM-file-sync-issue.png | 73 KB | pradeepjha |
Issue fork acquia_dam-3577492
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:
Comments
Comment #2
pradeepjha commentedComment #5
rajeshreeputraComment #6
rajeshreeputra@pradeepjha, please apply the patch from the current MR and let us know if it resolves the caching issue you are experiencing.
Comment #7
rajeshreeputra.
Comment #8
pradeepjha commented@rajeshreeputra, I tested this patch but unfortunately it didn’t work for me. I’m still seeing the same issue.
Comment #9
rajeshreeputraRequesting review.
Comment #10
pradeepjha commentedHi @rajeshreeputra
Cache‑busting has been applied; however, the application is still serving the outdated asset rather than the finalized version stored in the DAM. This suggests the issue is not related to caching.
Comment #11
pradeepjha commentedComment #12
rajeshreeputra@pradeepjha - Could you please share screenshots or a GIF of the issue for better context? Also, let us know if you're using the download and sync option.
Please confirm if the latest asset is reflected in Drupal by clicking
Check for updateon that specific asset. You should see:"The media item {filename} seems to be identical to the DAM asset it is associated with."
Note:
If you marked a previous version as finalized in DAM, it won't be picked up by cron. Use one of these options:
1. Click
Check for updatefor the asset2. Run
drush acquia-dam:queue-update-assets --finalized-versionthendrush cron3. Or run
drush acquia-dam:update-assets --finalized-version(skips cron)Thanks!
Comment #14
pradeepjha commented@rajeshreeputra Since it's a client website and accessed through VDI, I’m unable to share screen recordings or GIFs. However, I did try using “Check for update” and also ran the cron.
I also executed:
drush acquia-dam:queue-update-assets --finalized-version
to push newly finalized items from DAM into the Drupal queue, but that didn’t work either.
All of these tests were done in the Acquia Cloud IDE environment.
That said, everything started working again once we reverted the Acquia DAM module to version 1.1.9.
Comment #15
chakkche commentedit seems like $this->shouldRedownloadAsset is always returning FALSE both the local version id and asset version id are same.
In MediaItemUpdater.php after we have created a new version on the Media then we are trying to download the file which is causing the issue.
Updated the Queue worker to download the file before creating new version.
Comment #16
pradeepjha commentedComment #17
chakkche commentedComment #18
rajeshreeputra@pradeepjha - try MR patch from #3583037: Intermittent failure: assets in "Pending Delete" status failing to unpublish media in Drupal on top of these changes and provide your feedback.
Comment #19
chakkche commented@pradeepjha, @rajeshreeputra Can you please check the patch in comment #15 and provide feedback. Currently it is fixing the issue for me in one of my websites.
Comment #20
pradeepjha commentedHi @rajeshreeputra and @chakkche,
The patch works as expected on the latest version; however, the cron-related issue is still not resolved. In addition to applying the patch, a scheduled task needs to be configured to run the following command:
drush acquia-dam:queue-update-assets --finalized-versionThis scheduled execution is required to ensure that finalized asset versions are synced at the defined intervals.
Comment #21
pradeepjha commented.
Comment #23
rajeshreeputraValidated and created MR, requesting review.
Comment #24
rohan-sinha commentedworking as expected, files getting updated with new version sync, moving to RTBC.
Comment #25
rohan-sinha commentedComment #27
rajeshreeputraThanks @rohan-sinha, MR merged!