When the __queue__ is used to process sale, purchase and capture payments, we can see a concurrent issue with those processing method. It is not directly linked to the __queue__ but it allow to expose it (e.g. process multiple time a sale without any worker and then start a worker which will process in parallel the same sale multiple times).
I think we should lock the records for update like we do in Move.assign_try. At first a portable fix should be implemented and after we could probably have a method on the ModelSQL to lock instances.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
I may need to make clear what is happening. The process method of Sale and Purchase compute the differences between order and other documents (like shipment and invoice). When run in parallel on the same order, they create twice the same documents so the order is shipped or invoiced twice because the processes do not see each others and they do not modify the same tuple in the database to create a conflict. The goal of the lock is to create such conflict and so one of the thread will fail and retry later when the other one is finished and show its creation to the other thread.
Here is review45901002 for trunk which implements a new dualmethod ModelSQL.lock.
And review60511002 for 5.0 (and back-port) which add __lock on Model that needs it.
Cédric Krieradded 1 deleted label and removed 1 deleted label