Duplicate customer shipment after sale amendment

Support User
1

Hi,

We noticed a strange behavior with sale amendment. Sometimes, when a user is doing a sale amendment, shipment related to the sale is duplicated.
To solve the problem, we have to delete the first shipment linked to the sale.

This is not happening every time. There’s no error, except there are two shipments instead of one for the sale.

It seems “delete” here is not always applied: Blame · modules/sale_amendment/sale.py · branch/default · Tryton / Tryton · GitLab

Any idea about the problem ? Could we ensure that there’s the same number of shipments after the amendment ?

Thanks.

2

What do you mean? Is there two shipments with duplicated quantities? Is there just a leftover empty shipment?

3

yes, two shipments with duplicated quantities. Shipments are exactly the same.

4

What are their states and the states of the moves?
Are they grouped with other sales?

5

It’s a unique sale in processing state, shipment was in waiting state. No grouping. User made an amendment to change the shipping date.

Cannot reproduce the problem but it is the third time it happens. So we ask users to check the number of shipments after doing an amendment.

6

For me it is not comprehensive how the sale could create a new shipment if the previous outgoing moves are not deleted.
So I could understand that something prevent to delete the outgoing moves but then the processing of the sale should not create new moves.

7

I don’t understand myself how this could happen.

I retried to do the same amendment on the same sale on a cloned database and I cannot reproduce the behavior.

When deleting shipment in sale amendment, shipment is first cancelled and there is a decorator to process sale when doing a cancel on shipment out, so there’s a first call to sale process and then in the sale amendment after the clear_sale method, there’s another call to sale process. Maybe this could lead to duplicate shipments ?

8

At that point there should be no outgoing moves so no sale to process.

Even if process is called multiple times, there is a lock so it is sequential.

9

I think I found the reason for this behavior: Lock records is not enough to ensure to read last committed values (#13943) · Issues · Tryton / Tryton · GitLab
This can happen when using a pool of workers (and probably with higher probability on busy system).