Closed Codeweld closed 1 year ago
I found query that is causing deadlock, but do you know why is sylius_order
table updated on VSF refresh? I couldn't find which API end point is doing that. I run one by one end point in postman and sylius_order
table was not updated. Only on VSF refresh...
btw, I removed - doctrine_transaction
from middleware and problem still exists.
Thank you for sharing what you've discovered. We will look into that soon, it's a critical issue and has to be resolved.
That's a typical issue with sylius in asyc environments. Each api request, that triggers order_processing
can be executed in parallel for the same order, which will result in deadlocks, weird price adjustments, inconsistent totals. (This probably related as well https://github.com/BitBagCommerce/SyliusVueStorefrontPlugin/issues/68)
Reason is that order consist of several tables and doctrine transaction is not longer enough to ensure data consistency.
Solution is to wrap whole order_processing
in business transaction, for example with pessimistic lock via symfony/lock
Something like LockingOrderProcessor
, which will decorate CompositeOrderProcessor
with appropriate priority should do the trick.
More on the topic https://github.com/Sylius/ShopApiPlugin/issues/667
The current solution is deprecated as it was created for Vue Storefront v1. For Vue Storefront 2 integration check out our GraphQL-based integration - https://github.com/BitBagCommerce/SyliusVueStorefront2Plugin
Current behavior
It happens that deadlock occurs during standard operations in VSF. It is related to
Timestampable
which is trying to modifyupdated_at
of currently processed object.Expected behavior
Deadlocks should not happen.
Steps to reproduce the issue
It occurs during standard operations in VSF, just:
Suggested steps to fix the issue
doctrine_transaction
middleware in messenger