The cron job is repeatedly logging error messages.

Thanks for reporting the issue and providing a possible fix to solve. I'd suggest let's wait with this until 📌 Handling media items when their asset gets unavailable in Widen Postponed lands, then we will see a clearer picture of how could be the asset synchronisation and queue management optimised further.

This is the issue that I reported in https://www.drupal.org/project/acquia_dam/issues/3471261 📌 Missing integration links Needs review . I didn't have a solution in that issue, but it has a MR to improve the error message that's logged, which would be helpful even when this issue is fixed.

I see that this issue is postponed but I had previously applied this patch to test out.

It does prevent the GET request from throwing the exception, which allows the integration links to be deleted. However, I found that it just generated new batches of warnings/errors on every cron afterwards. It was never the same messages in the logs. That make me think that this isn't the complete solution.

@capysara - The fix was designed to log warnings for assets that have already been deleted from the DAM, particularly when the queue process attempts to delete assets that no longer exist.

I found that it just generated new batches of warnings/errors on every cron afterwards. It was never the same messages in the logs. That make me think that this isn't the complete solution.

Could you please confirm if you're seeing multiple warnings for the same assets that were processed in the previous cron run, particularly for the integration delete?

About the new batches of warnings and errors: These fixes enable the queue to process items without terminating the process. Therefore, whenever the queue is processed, any issues with the asset references will generate warnings and errors in the logs once.

Reviewed changes, looks good to me assuming 400 status code returned by Widen DAM only in case of scenarios where assets are being deleted/removed directly on Widen DAM portal.
Hence, RTBC.

MRs of bugfixes should target the 1.0.x branch.

capysara → changed the visibility of the branch 3476119-3476119-fix-integration-link-1.0 to hidden.

Created MR against 1.0.x.

itsruanduplessis → changed the visibility of the branch 3476119-3476119-fix-integration-link-1.0 to active.

itsruanduplessis → changed the visibility of the branch 3476119-fix-integration-link to hidden.

Step 4. of the reproduction process says:

“Delete the attached media from site as well as from DAM”

At this point, this issue relates to 📌 Handling media items when their asset gets unavailable in Widen Postponed , where I am working on covering such situations (aka. the asset has been gone in Widen, but Drupal still tries fetching its data.)

So during my testing, I found that not only removeIntegrationLink(), but 3 other methods of our AcquiaDamClient are also affected by some unhandled 4xx errors (this MR checks for “400”, but in my case, it's “404”). These methods are:

• getAsset()
• getAssetVersions()
• registerIntegrationLink()

Basically, whenever the API request contains the UUID of a given asset (or an integration link), then we need to take care of handling those 4xx errors. Methods of non-specific, generic requests seem to be unaffected.

To avoid code duplication 4 times in total, I created an internal method responsible for logging the exception message. For those, who are interested, I can link my commit dee3b744 in its current state (no MR is opened yet to link to).

Leaving this ticket open until aforementioned 📌 Handling media items when their asset gets unavailable in Widen Postponed lands, then we can return back here to try out the scenario described again and if it seems to be solved, then extend the test coverage under a new MR of this ticket.

Closing as this work has been made part of 📌 Handling media items when their asset gets unavailable in Widen Postponed which takes larger approach to solving the deleted items issue in Drupal.

japerry → closed merge request !85