-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix ability to query bulk operations across multiple bulk_uuid values (broken by 2.4 release) #29579
base: 2.5-develop
Are you sure you want to change the base?
Fix ability to query bulk operations across multiple bulk_uuid values (broken by 2.4 release) #29579
Conversation
…rement ID as the key for collection building. This resolves an issue where performing a search that covers more than 1 bulk_uuid would throw an error since the collection builder attempts to re-use an existing array key when the same operation_key exists for both bulk_uuids
…o cover the bug being resolved by this fix.
…collection_loading
Hi @moloughlin. Thank you for your contribution
❗ Automated tests can be triggered manually with an appropriate comment:
You can find more information about the builds here ℹ️ Please run only needed test builds instead of all when developing. Please run all test builds before sending your PR for review. For more details, please, review the Magento Contributor Guide documentation. 🕙 You can find the schedule on the Magento Community Calendar page. 📞 The triage of Pull Requests 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 run WebAPI |
@magento create issue |
@magento run WebAPI Tests |
@magento run all tests |
@magento run all tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix failing tests
/** | ||
* @inheritDoc | ||
*/ | ||
public function getOperationKey() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing return type on prototype
/** | ||
* @inheritDoc | ||
*/ | ||
public function setOperationKey(int $operationKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing return type on prototype
Hi @moloughlin, thanks for the contribution, can you address the review comments? I will re-run the tests, we will have to address the failing tests if we get them. |
@magento run all tests |
Hi @moloughlin can you review the failing tests? I think the proposed changes may causing some other problems. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔ Approved.
Failing tests looks not related to changes form this PR.
@@ -91,7 +91,7 @@ public function createByTopic($topicName, $entityParams, $groupId, $operationId) | |||
]; | |||
$data = [ | |||
'data' => [ | |||
OperationInterface::ID => $operationId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't forget this class exists as well in the webapi async module, and needs to be changed there as well.
Magento/WebApiAsync/Model/OperationRepository.php:92
@@ -91,7 +91,7 @@ public function createByTopic($topicName, $entityParams, $groupId, $operationId) | |||
]; | |||
$data = [ | |||
'data' => [ | |||
OperationInterface::ID => $operationId, | |||
OperationInterface::OPERATION_KEY => $operationId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should not work correctly.
OPERATION_KEY - its a DB key for "operation_key" column.
if you switch OPERATION_KEY to "id", it will stop working, cause $operationId here is a key of array, and in database "id" is an auto_increment value. And in case of multiple operations, will be duplicated for different bulk operations.
Implementing of OPERATION_KEY was done in purpose, for decouple operation keys from database increments and improve performance on saving big operations.
Another issue, it that not all Magento API functionality have a tests coverage, so we overslept broken another part of API
Description (*)
The 2.4 release broke our ability to query Bulk Operations by status or start_date. Any attempt to do so causes an exception response:
"Item (Magento\\AsynchronousOperations\\Model\\Operation) with the same ID \"0\" already exists.",
Steps to Recreate
POST two bulk loads into Magento REST - confirm that two magento_bulk records are created, and magento_operation records (depending on number of items in the bulk load). You'll see that for each bulk_uuid, the operation_key is sequential, e.g:
Query the operations via
/rest/V1/bulk/?searchCriteria[filter_groups][0][filters][0][field]=status&searchCriteria[filter_groups][0][filters][0][value]=1&searchCriteria[filter_groups][0][filters][0][condition_type]=eq"
(change thestatus
filter value to suit your message status, as long as there are two messages with the same operation_key and same status)Receive the noted exception response.
Root Cause
\Magento\Framework\Data\Collection\AbstractDb::loadWithFilter
=>
\Magento\Framework\Data\Collection::addItem
=>
\Magento\Framework\Data\Collection::_getItemId
=>
\Magento\AsynchronousOperations\Model\Operation::getId
In 2.4, the getId method of the Operation model was (incorrectly IMO) changed to return the
operation_key
value. But theoperation_key
is NOT a unique value - I believe that should have been added as a new field on the model, and that the existing ID field (mirroring the SQL autoincrement unique value) remains used for the array index when building the collection:Contribution checklist (*)
Resolved issues: