[brendon]

Depends on #71 (and so #70), which change the same lines. This branch includes their commits, so review just the last commit, or wait until they're merged and the diff shrinks to this change.

Under MySQL's default REPEATABLE READ isolation, a plain SELECT reads the snapshot taken at the transaction's first read, while UPDATEs always act on the latest rows. If anything read in the transaction before we took the lock, and another transaction moved records while we waited for it, then position_was, last_position and the relative record's position came from stale data while expand/contract operated on current rows.

Any read before the lock is enough: a uniqueness validation, a belongs_to presence check that loads the parent, a callback, or app code in a surrounding transaction.

The new test reads inside the transaction, waits on the lock while another transaction inserts at position 1, then moves a record. On main, MySQL:

ActiveRecord::RecordNotUnique: Mysql2::Error: Duplicate entry '1-1-2' for key 'authors.index_authors_on_list_id_and_enabled_and_position'

and on a table without a unique index it silently produced [1, 2, 2, 4, 5, 6] (a duplicate 2 and a missing 3). PostgreSQL (READ COMMITTED takes a new snapshot per statement) and SQLite were already fine; the test passes on them either way.

Fix

Make those reads locking reads (FOR UPDATE), which always see the latest committed rows. MAX() can't be combined with FOR UPDATE on PostgreSQL, so the maximum is read as the top row instead, with NULLs excluded since PostgreSQL sorts them first when descending. These are rows we already hold the scope lock for and are about to update anyway.

Changelog: Fix stale position reads on MySQL (REPEATABLE READ) after waiting for the scope lock.

🤖 Generated with Claude Code