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() involving finalized-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

  1. Install acquia_dam version 1.1.10, 1.1.11, or 1.1.12.
  2. In Acquia DAM, create a document with multiple versions.
  3. Upload a new document version and mark it as finalized.
  4. In Drupal, run cron multiple times using Acquia Cloud IDE.
  5. Open the corresponding media entity in Drupal.
  6. Expected: Drupal should display the latest finalized version.
  7. 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-version inside AssetUpdater::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-version metadata.
  • 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

Issue fork acquia_dam-3577492

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:

Comments

pradeepjha created an issue. See original summary.

pradeepjha’s picture

StatusFileSize
new73 KB

rajeshreeputra made their first commit to this issue’s fork.

rajeshreeputra’s picture

Status: Active » Needs work
rajeshreeputra’s picture

@pradeepjha, please apply the patch from the current MR and let us know if it resolves the caching issue you are experiencing.

rajeshreeputra’s picture

.

pradeepjha’s picture

@rajeshreeputra, I tested this patch but unfortunately it didn’t work for me. I’m still seeing the same issue.

rajeshreeputra’s picture

Status: Needs work » Needs review

Requesting review.

pradeepjha’s picture

Hi @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.

pradeepjha’s picture

Status: Needs review » Needs work
rajeshreeputra’s picture

@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 update on 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 update for the asset
2. Run drush acquia-dam:queue-update-assets --finalized-version then drush cron
3. Or run drush acquia-dam:update-assets --finalized-version (skips cron)

Thanks!

  • rajeshreeputra committed 6cce7b78 on 1.1.x
    Resolve #3577492 "Fix: Update embed link url to include version id in...
pradeepjha’s picture

@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.

chakkche’s picture

it 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.

pradeepjha’s picture

Version: 1.1.12 » 1.1.13
chakkche’s picture

Version: 1.1.13 » 1.1.x-dev
Status: Needs work » Needs review
rajeshreeputra’s picture

@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.

chakkche’s picture

@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.

pradeepjha’s picture

Hi @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-version

This scheduled execution is required to ensure that finalized asset versions are synced at the defined intervals.

pradeepjha’s picture

.

rajeshreeputra’s picture

Validated and created MR, requesting review.

rohan-sinha’s picture

working as expected, files getting updated with new version sync, moving to RTBC.

rohan-sinha’s picture

Status: Needs review » Reviewed & tested by the community

  • rajeshreeputra committed 34626fbc on 1.1.x
    Resolve #3577492 "Fix media update queue to download new file when...
rajeshreeputra’s picture

Status: Reviewed & tested by the community » Fixed

Thanks @rohan-sinha, MR merged!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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