Lock records is not enough to ensure to read last committed values
Similar to #10870 (closed) but when locking records (with SELECT...FOR UPDATE).
For example, this creates problems when multiple tasks are posted to process the same sale: https://discuss.tryton.org/t/duplicate-customer-shipment-after-sale-amendment/8418 What may happen is that the second task is started before the first one is finished but the first one is committed before the second one reach the lock of the record. So the second task is running seeing data as they were before the first task (so with a shipment missing).
I think we should implement the same mechanism as for locking table so the records are locked at the transaction starts.
Related merge requests 1
When this merge request is accepted, this issue will be closed automatically.
Activity
added trytond type::behavior labels
assigned to @ced
mentioned in commit f9b6e5789cbc
mentioned in merge request !2300
As this issue can lead to data "corrupted" (wrongly calculated), I think it should be backported to all the series that already has c8771e45b861 even if this changing the API.
mentioned in commit f57895315364
mentioned in commit 767e2f252305
mentioned in commit a71a15354ab1