decentraland / social-service-ea / 31826974647

91%

main: 91%

Pull #491

github

fix: one friendship per pair, whichever way round it was created

unique_addresses covers the ordered columns, so A→B and B→A are different tuples
and both insert. The last-action read that chooses between insert and update runs
outside the transaction, so two people requesting each other at the same moment
both take the insert branch.

Every lookup matches either direction with no LIMIT, so a duplicated pair makes
reads non-deterministic — and deactivating "the" friendship, as blocking does,
updates one row and leaves the other active, so the pair still reads as friends
after a block. Reproduced on PostgreSQL 15.

Adds a unique index on the unordered pair, and an ON CONFLICT that returns the
row that won rather than raising, so the loser records its action against the
same relationship instead of the request failing.

The migration merges existing duplicates first, since the index cannot be created
over them. The active row wins, oldest first as a tiebreak: that cannot silently
unfriend anyone, which the reverse policy could. friendship_actions.friendship_id
has no foreign key, so the losing rows' history is repointed at the survivor
rather than orphaned — getLastFriendshipActionByUsers inner-joins friendships, so
an orphaned action would take the state machine's view of the relationship with
it.

Verified against seeded duplicates covering each branch — newer-active beating
older-inactive, both-active falling back to oldest, both-inactive falling back to
oldest, and a non-duplicated pair left alone — with every action still resolving
to a surviving row afterwards. The reverse-direction insert is refused after the
index exists, a new pair still inserts, and down() then up() is clean.

2594 of 2992 branches covered (86.7%)

Branch coverage included in aggregate %.

6244 of 6696 relevant lines covered (93.25%)

93.6 hits per line