Pune
Account created on 26 May 2014, almost 11 years ago
  • Sr. Software Engineer at Acquia 
#

Merge Requests

More

Recent comments

🇮🇳India chandu7929 Pune

Passing a blank string serves as a workaround to bypass the error. Ideally, we should update the method signature to accept null as an optional parameter. However, it's unclear what the implications of passing null might be, although all tests are currently passing with this change.

🇮🇳India chandu7929 Pune

Hello @Japerry,

The optional parameter should be set to null rather than an empty string—unless there's a specific reason to use an empty string in the method. Using an empty string can cause an error when the function is called without the second parameter, as it expects a value of type string. This results in the following error:

"Argument #2 ($version_id) must be of type string",

which is inaccurate in this context.

Please refer to the error trace from the getAsset() call in media_acquiadam where version_id is not passed.

 [error]  Client error: `GET https://api.widencollective.com/v2/assets/0c772875-c010-47af-bf7e-2a2080587d50/versions?expand=asset_properties,embeds,file_properties,metadata,metadata_info,metadata_vocabulary,security,thumbnails` resulted in a `404 Not Found` response:
> {
>   "error": true,
>   "response_code": 404,
>   "error_message": "Asset with UUID 0c772875-c010-47af-bf7e-2a2080587d50 not  (truncated...)
>  [error]  TypeError: Drupal\acquia_dam\Client\AcquiaDamClient::getAsset(): Argument #2 ($version_id) must be of type string, null given, called in /var/www/html/web/modules/contrib/acquia_dam/src/Plugin/media/Source/Asset.php on line 234 in Drupal\acquia_dam\Client\AcquiaDamClient->getAsset() (line 170 of /var/www/html/web/modules/contrib/acquia_dam/src/Client/AcquiaDamClient.php) #0 /var/www/html/web/modules/contrib/acquia_dam/src/Plugin/media/Source/Asset.php(234): Drupal\acquia_dam\Client\AcquiaDamClient->getAsset()
🇮🇳India chandu7929 Pune

Overall, the changes in MR!47 look good to me. I validated the behavior using both private://myfile.key and public://myfile.key paths, and was able to retrieve the key value when using this patch. However, without the patch, the value returns null. Therefore, marking this as RTBC.

🇮🇳India chandu7929 Pune

Updated variable name as requested, hence moving in NR.

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

Incorporated requested changes, hence requesting review.

🇮🇳India chandu7929 Pune

@japerry - Thank you for highlighting first point; we will take it into consideration for inclusion. However, regarding your second point,

Also, the media type labels are greyed out. The ones that come with Acquia DAM should be editable alongside the old Media: Acquia DAM types so you can get a full picture of the all the media types and their names.

What is the reasoning behind permitting updates to the media labels of the new media type provided by the Acquia DAM module, despite the apparent logic in offering label modification options for the older media types?

🇮🇳India chandu7929 Pune

Since all requested changes are done, hence requesting review.

🇮🇳India chandu7929 Pune

Updated MR with required changes, hence requesting review.

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

chandu7929 changed the visibility of the branch 1.0.x to hidden.

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

Thanks for the feedback, @vishal! I've refactored the code and improved the logic based on your suggestions.

🇮🇳India chandu7929 Pune

The requested changes have been incorporated. Hence NR

🇮🇳India chandu7929 Pune

Updated MR with required changes hence requesting review.

🇮🇳India chandu7929 Pune

chandu7929 changed the visibility of the branch 3500484-media-view-display to hidden.

🇮🇳India chandu7929 Pune

chandu7929 changed the visibility of the branch 3500484-media-view-display to active.

🇮🇳India chandu7929 Pune

Pulling back in NW since its not working as expected.

🇮🇳India chandu7929 Pune

Verified this chagnes with Migration issue 🐛 Media view display handling not honored during migration Active , this completly make sence to update external_id in this queue working this is the most appropriate place, rather creating new process and make a whole seprate API call again to get assest and update it.

RTBC.

🇮🇳India chandu7929 Pune

Verified the migration with latest changes, and I can confirm that its working as expected. Also I like the idead of using existing queue worker to update asset with external_id becuase we already making api call to get asset details.

Hence RTBC

"Warning: Attempt to read property "asset_id" on null in acquia_dam_media_delete() (line 696 of /var/www/html/upstreams/acquia_dam/acquia_dam.module).

acquia_dam_media_delete(Object)"

Not able to replicate this issue.

🇮🇳India chandu7929 Pune

We are not going to take these block in recipe:

  1. block.block.views_block__article_cards_recent_articles_block.yml
  2. block.block.views_block__event_cards_past_events_block.yml
  3. block.block.views_block__event_cards_upcoming_events_block.yml

Hence closing MR!44

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

I have fixed most of the failing tests only 2 similar test are failing.

  1. Drupal\Tests\quickedit\FunctionalJavascript\LayoutBuilderIntegrationTest::testArticleNode - This caused by empty body field value
  2. Drupal\Tests\quickedit\FunctionalJavascript\CKEditor5IntegrationTest::testArticleNode - Not sure why saving state isn't available for body field
🇮🇳India chandu7929 Pune

The remaining tests are failing because the library quickedit.inPlaceEditor.formattedText is not attached during testing. I will investigate further to determine the root cause.

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

@damienmckenna Thank you for your insights. I’ll mark this issue as closed (won't fix).

🇮🇳India chandu7929 Pune

Add all commits from 📌 GitLab CI testing Needs review to make sure all test are passing for this issue as well.

🇮🇳India chandu7929 Pune

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

🇮🇳India chandu7929 Pune

Verified recent changes and it looks good to me. I would request another sets of eyes.

🇮🇳India chandu7929 Pune

@Rajeshreeputra - Requested some changes, please take a look.

🇮🇳India chandu7929 Pune

I have verified the attached patch which fixes the issue. Needs review.

"patches": {
            "drupal/acquia_search": {
                "Acquia Search can lock threads excessively leading to denial of service on cache clear": "https://www.drupal.org/files/issues/2024-09-10/acquia_serach-3466306.patch"
            }
        }
🇮🇳India chandu7929 Pune

Added test and CI is green, hence requesting review.

🇮🇳India chandu7929 Pune

Hello Yuvania lets make changes related to D11 compatibility fixes only. We should create separate issue for phpcs, eslint etc.

Production build 0.71.5 2024