fix(parity): compare playlists_containing_track as a set, accept duration NULL->0

[rickyrombo]

Two sources of noise on tracks, together 434 of 3,526 sampled rows — none of them a defect the migration can fix.

Ordering

The reference array is the order playlists were appended and removed over that track's history. It is not derivable from any column.

• 63% of multi-playlist tracks carry one identical backfill created_at across every row
• Where timestamps do differ, the array still doesn't follow them — track 4740 lists a Jul 13 entry before a Jul 10 one

The migration replays playlist_tracks grouped by playlist_id, so its arrays come out ascending:

track 790: etl=[123 1171 12925 13642 19896]
      reference=[1171 13642 19896 12925 123]

Sorting both sides compares the membership we can reproduce instead of failing on an ordering nobody can.

Multiplicity

The reference appends unconditionally, so a track added to one playlist repeatedly is listed repeatedly:

track 161160: etl=[18598 18601] reference=[18598 18601 18601 18601 18601 18601 18601 18601 18601]

The indexer dedupes on purpose — it checks @> ARRAY[id] before appending. Comparing multisets reports a divergence the indexer is designed to create.

duration

The reference leaves it NULL when unknown; the indexer writes 0 (~99k tracks). Accepted as no semantic difference — absence and zero both mean "no duration known" — so it moves to KnownDiffs and is reported rather than counted as a mismatch.

Result

	before	after
match rate	87.7%	99.9%
mismatched	434	3

The 3 remaining are real membership differences and stay visible, as do the whole-table in_playlists aggregates that catch over- or under-population.

🤖 Generated with Claude Code