Wrong handling some of asynchronous bulk operations and related mysql queue messages in Magento 2.4.0

[Neos2007]

Preconditions (*)

1. Magento version: 2.4.0
2. Configured cron for running message queue consumers.

Steps to reproduce (*)

1. On the product grid in the backend perform massaction to update attribute values for couple products ("check" products and select "Update Attributes" action from "Actions" dropdown).
2. Set values for needed attributes or/and assign products to websites and save.
3. After the page reloads will be displayed a message like "Task "Update attributes for N selected products": 1 item(s) have been scheduled for an update."
4. Wait some time and reload the backend page.

Expected result (*)

1. Displayed messages like "1 item(s) have been successfully updated...".
2. Attribute values for related products updated.
3. In DB new record in "magento_bulk" and new record(s) in "magento_operation" table (operations related to the bulk).
4. New record(s) in the "queue_message" (related to the queues "product_action_attribute.update" and/or product_action_attribute.website.update) and new related record(s) in the "queue_message_status" table with status "4".

Actual result (*)

1. In system messages still displayed a message like "Task "Update attributes for N selected products": 1 item(s) have been scheduled for an update."
2. Attribute values for the products updated.
3. A new record in "message_bulk" table but no related record(s) in "magento_operation" table.
4. New related records in "queue_message" and "queue_message_status" tables but records in the last table with error stauts (status value "6").
5. In magento system.logs added string with error: main.CRITICAL: Message has been rejected: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'operation_key' cannot be null, query was: INSERT INTO magento_operation (id, bulk_uuid, topic_name, serialized_data, result_serialized_data, status, error_code, result_message, operation_key) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) [] []

During debugging I found out that since Magento 2.4.0 version into "magento_operation" table was added new required (not nullable) column 'operation_key'. But neither controller action which schedules updated product attributes update bulk (\Magento\Catalog\Controller\Adminhtml\Product\Action\Attribute\Save::publish()) nor consumer which executes related messages and updates bulk status(\Magento\Catalog\Model\Attribute\Backend\Consumer::process()) does setting "operation_key" value into related operation. And during an attempt to save operation in the consumer (app/code/Magento/Catalog/Model/Attribute/Backend/Consumer.php:140) trows exception. As result operation is not saved and the status of the reladed message in the "queue_message_status" saved with value "6".

Also, the same problem for code that pushes/handles bulks related to the "media.storage.catalog.image.resize" queue.

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @Neos2007. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[magento-engcom-team]

✅ Confirmed by @engcom-Alfa
Thank you for verifying the issue. Based on the provided information internal tickets MC-37334 were created

Issue Available: @engcom-Alfa, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[gabrieldagama]

Hi @Neos2007. Thank you for your report.
The issue has been fixed in #29814 by @nuzil in 2.4-develop branch
Related commit(s):

• 09b63c7e378eea2db2453653b1348eb33e45600d
• 2450b144b5172b5aa45e582d836c5529841fad14
• 77d62ef15b1092d8869aa6dfbcd419effd157beb
• 4da31ea9c11948ca6853524295fa5276c5c5ff9b
• a0e65ed26f6b31fcff0eec02c72a1da1ffa86938
• 5c87afec15469461c402c6b6b0bfee0997eae40d

The fix will be available with the upcoming 2.4.2 release.