decentraland / atlas-server / 33003365802

42%

push

github

fix: apply the V3 trade status semantics to the map query (#144)

> ⚠️ **Deploy last.** This query now reads two columns other repos
create. See *Deploy order* — getting it wrong empties the map silently
rather than erroring.

## What

`atlas-server` is the second consumer of `squid_trades`, and its
trade-status query carried every defect just fixed in
`marketplace-server#395`. `getActiveTrades` feeds
`src/modules/map/component.ts`, so the symptom is **parcels and estates
showing as for sale when they are not**.

Found while auditing who actually reads that schema for the V3 rollout.
Nobody had looked at this query; the reviews on the marketplace PRs only
covered marketplace-server and the indexer.

## The five defects

**Cancellations counted any row, regardless of who cancelled.**
`cancelSignature` takes no signer check, and the contract scopes the
flag to `keccak256(caller, digest)` while settlement reads
`keccak256(signer, digest)` — so a stranger cancelling somebody's trade
is a no-op on chain. Counting it here meant anyone could grief a listing
off the map, using trade data the marketplace API publishes, while the
listing stayed settleable.

**Cancellations were matched only on `keccak256(signature bytes)`.** V3
keys them on the trade's EIP-712 digest, so a V3 cancellation would
never have resolved and cancelled V3 land would have stayed on the map
indefinitely.

**The signer index was matched on `address` alone.** A `signature_index`
row's identity is `address + contract + network`, so that returns
several rows, which splits one trade into several `GROUP BY` groups with
contradictory statuses. Because this query then keeps only `status =
'open'`, **the stale group is the one that survives.** This is the
defect that most directly puts a cancelled listing back on the map, and
it gets more likely with V3 live, since the same signer now holds an
independent counter per marketplace version.

**The contract index was a hardcoded list containing only ... (continued)

298 of 412 branches covered (72.33%)

Branch coverage included in aggregate %.

30 of 30 new or added lines in 1 file covered. (100.0%)

1488 of 3886 relevant lines covered (38.29%)

11.95 hits per line