Message Queue consumer issue : context is not reset between messages

Nuranto commented 1 year ago

Preconditions and environment

Magento version 2.4.6-p2

Steps to reproduce

Create a command test:publish_message that publish a message on a queue
Create a consumer that loads and display a product stock qty (via stock registry), and logs it. (initial qty = 100)
Launch the consumer
Run the test:publish_message
Edit the qty of the product on backend (qty : 200)
Run the test:publish_message
Check consumer's logs

Expected result

Logs should display :

100
200

Actual result

Logs display :

100
100

Additional information

This is because both messages are running in the same environement, without any reset of any kind.

With a high value of --max-messages or with consumers-wait-for-messages a consumer can run for days before restarting. This can have very bad consequences for some consumers.

I guess the easiest and safest solution is to run the message execution in a new process. But maybe it could also do the trick to - somehow - reset ObjectManager between each messages (But I'm afraid about memory consumption with that).

Workaround :

(with --consumers-wait-for-messages=1)

while true; do bin/magento queue:consumers:start --max-messages=1 -vvv consumer.name; done

This is a lot slower :/ but it solves the issue while waiting for a fix.

Release note

No response

Triage and priority

[ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
[X] 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[bot] commented 1 year ago

Hi @Nuranto. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release
For more details, review the Magento Contributor Assistant documentation.
Add a comment to assign the issue: @magento I am working on this
To learn more about issue processing workflow, refer to the Code Contributions.

Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

m2-assistant[bot] commented 1 year ago

Hi @engcom-Hotel. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
[ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop branch
Details
- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 5. Add label Issue: Confirmed once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

engcom-Hotel commented 1 year ago

Hello @Nuranto,

Thanks for the report and collaboration!

We have tried to reproduce the issue in Magento 2.4-develop branch and the issue is reproducible for us. We have used the below codebase to get to quantity of the product in consumer:

            $productSku = 'SimpleProduct1';
            $product = $this->productRepository->get($productSku);
            $stockItem = $this->stockRegistry->getStockItem($product->getId());
            $quantity = $stockItem->getQty();
            $message = $quantity . PHP_EOL;
            file_put_contents('CUSTOM_PATH/log.txt', $message, FILE_APPEND);

It is always returning the initial stock value even after reindexing and cache clear:

bin/magento indexer:reindex && bin/magento c:f

Hence confirming the issue.

Thanks

github-jira-sync-bot commented 1 year ago

:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-9549 is successfully created for this GitHub issue.

m2-assistant[bot] commented 1 year ago

:white_check_mark: Confirmed by @engcom-Hotel. Thank you for verifying the issue.
Issue Available: @engcom-Hotel, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

abhishek-omnia commented 6 months ago

@engcom-Hotel any updates regarding these issue i am also facing this issue i am not able to find solution

gorbunovav commented 1 month ago

Magento often relies on a very basic caching approach, where loaded entities are stored in an instance's private field. However, unlike with HTTP requests, the context doesn't reset while a consumer is running. This means that message handlers remain completely unaware of any external changes, including those from other consumers running in separate processes.

The potential for data inconsistencies here is enormous.

And you don't need the consumer to run for a long time - just enough to have an external data change between two messages processing.

AndresInSpace commented 3 weeks ago

Magento often relies on a very basic caching approach, where loaded entities are stored in an instance's private field. However, unlike with HTTP requests, the context doesn't reset while a consumer is running. This means that message handlers remain completely unaware of any external changes, including those from other consumers running in separate processes.

The potential for data inconsistencies here is enormous.

And you don't need the consumer to run for a long time - just enough to have an external data change between two messages processing.

I haven't dug into the underlying code yet, but it sounds like you are saying once the consumer messages model loads a product the product model is cached in the instance (as magento does) and thus subsequent messages loading same product id are serving from instance cache (memory) rather than a new db query result?

magento / magento2