Skip to content
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

Open
wants to merge 13 commits into
base: 2.5-develop
Choose a base branch
from

Conversation

moloughlin
Copy link

@moloughlin moloughlin commented Aug 17, 2020

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:

<first_bulk_uuid>, 0
<first_bulk_uuid>, 1
<first_bulk_uuid>, 2
...
<second_bulk_uuid>, 0
<second_bulk_uuid>, 1
<second_bulk_uuid>, 2
...

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 the status 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 the operation_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:

    public function addItem(DataObject $item)
    {
        $itemId = $this->_getItemId($item);

        if ($itemId !== null) {
            if (isset($this->_items[$itemId])) {
                //phpcs:ignore Magento2.Exceptions.DirectThrow
                throw new \Exception(
                    'Item (' . get_class($item) . ') with the same ID "' . $item->getId() . '" already exists.'
                );
            }
            $this->_items[$itemId] = $item;
        } else {
            $this->_addItem($item);
        }
        return $this;
    }

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • [TBC] All automated tests passed successfully (all builds are green)

Resolved issues:

  1. resolves [Issue] Fix ability to query bulk operations across multiple bulk_uuid values (broken by 2.4 release) #29580: Fix ability to query bulk operations across multiple bulk_uuid values (broken by 2.4 release)

Matthew O'Loughlin added 3 commits August 17, 2020 22:22
…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.
@m2-assistant
Copy link

m2-assistant bot commented Aug 17, 2020

Hi @moloughlin. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento give me test instance - deploy test instance based on PR changes
  • @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

  • @magento run all tests - run or re-run all required tests against the PR changes
  • @magento run <test-build(s)> - run or re-run specific test build(s)
    For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

  1. Database Compare
  2. Functional Tests CE
  3. Functional Tests EE,
  4. Functional Tests B2B
  5. Integration Tests
  6. Magento Health Index
  7. Sample Data Tests CE
  8. Sample Data Tests EE
  9. Sample Data Tests B2B
  10. Static Tests
  11. Unit Tests
  12. WebAPI Tests

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.

⚠️ According to the Magento Contribution requirements, all Pull Requests 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 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

@moloughlin
Copy link
Author

@magento run WebAPI

@sidolov
Copy link
Contributor

sidolov commented Aug 17, 2020

@magento create issue

@sidolov sidolov added Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Severity: S2 Major restrictions or short-term circumventions are required until a fix is available. labels Aug 17, 2020
@moloughlin
Copy link
Author

@magento run WebAPI Tests

@moloughlin
Copy link
Author

@magento run all tests

@BarnyShergold BarnyShergold self-assigned this Aug 21, 2020
@BarnyShergold
Copy link

@magento run all tests

Copy link

@BarnyShergold BarnyShergold left a 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()

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)

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

@gabrieldagama
Copy link
Contributor

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.

@gabrieldagama
Copy link
Contributor

@magento run all tests

@gabrieldagama
Copy link
Contributor

Hi @moloughlin can you review the failing tests? I think the proposed changes may causing some other problems. Thanks!

@engcom-Charlie engcom-Charlie self-assigned this Sep 25, 2020
Copy link
Contributor

@ihor-sviziev ihor-sviziev left a 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,
Copy link
Contributor

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,
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Auto-Tests: Covered All changes in Pull Request is covered by auto-tests Award: bug fix Award: test coverage Component: AsynchronousOperations Component: Bulk Partner: Aligent Consulting partners-contribution Pull Request is created by Magento Partner Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Progress: pending review Release Line: 2.5 Severity: S2 Major restrictions or short-term circumventions are required until a fix is available.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Issue] Fix ability to query bulk operations across multiple bulk_uuid values (broken by 2.4 release)