decentraland / marketplace-server / 30923252019

61%

push

github

fix: stop the duplicate-order guard splitting one trade into two statuses (#381)

* fix: stop the duplicate-order guard splitting one trade into two statuses

An item whose order had been executed at least once and then cancelled became PERMANENTLY
unlistable. Creating a new listing was rejected with "There is already an open order for this
Item", while the Shop catalogue and the Builder both correctly showed the item as not for sale —
so nothing in any UI pointed at the listing doing the blocking.

Cause. squid_trades.trade holds one row per ON-CHAIN ACTION, and their callers differ: a
cancellation is called by the signer, an execution by whoever bought (a contract, for a relayed
or credits-funded purchase). getTradesForTypeQuery grouped by trade_status.caller, so one trade
became one group per caller and the status CASE was evaluated inside each: the group holding the
cancellation counted it and returned cancelled, the group holding the execution counted no
cancellation, fell through every branch and returned open. Two contradictory rows for one trade.

getOpenItemOrderQuery and getOpenNFTOrderQuery then do WHERE status = 'open' LIMIT 1, which finds
the phantom row. getTradesForTypeQueryWithFilters — what the catalogue reads — never grouped by
caller, which is why the two disagreed and why the UIs looked right.

caller was in the GROUP BY only because the status CASE referenced it, in an extra
`AND t.signer = trade_status.caller` that the filtered query does not have. Removing that
reference is what allows grouping by the trade, which is the unit a status describes. The two
status computations are now identical.

Note the precedence in the clause that was removed: AND binds tighter than OR, so it read as
`condA OR (condB AND caller = signer)` rather than gating the whole branch — a second reason it
did not mean what it appeared to.

Verified against a real database (dev), not just by reading:

- Before: the guard returned 1 row for the affected item... (continued)

1626 of 3082 branches covered (52.76%)

Branch coverage included in aggregate %.

2953 of 4428 relevant lines covered (66.69%)

22.66 hits per line