[rameerez]

CI's MySQL job (the one leg that can't run locally) fails three escalation race tests on main: two flags on one content remove it twice, and two flags on different fields or different content ban the person twice. PostgreSQL and SQLite pass.

Why

Under MySQL's default REPEATABLE READ, a plain SELECT returns the transaction's consistent snapshot. That snapshot is taken at the first plain read, which here was the plain reload right after with_lock, before the content's and the person's locks were granted. The second worker, once it had the lock, still saw no covering decision, no prior ban and the content still there, so it enforced again. PostgreSQL's READ COMMITTED (and SQLite's serialized writers) never showed this.

What

Every check that decides "already done" under a lock is now a locking read, the same on all three databases, with nothing special-cased for MySQL:

• the covering decision and the open-report lookup in ResolveFlag: .lock;
• whether the content is gone: reload(lock: true);
• the per-person prior ban in ResolveReport: .lock;
• Flag.flag_for_review!'s waiting flag: .lock.

The redundant plain reloads after with_lock (which already re-reads the row FOR UPDATE) are gone from ResolveFlag, ResolveReport and ResolveAppeal. Lock order is unchanged: flag, content, person, report.

Second fix, found by CI. The first push passed on MySQL, but the beta4 head then deadlocked once, in the same-person, different-content ban race. The new locking reads on moderate_reports take gap locks under REPEATABLE READ. Both escalations ran their covering read before the person's lock, so each held a gap lock that the other's report INSERT needed, while waiting on the person's lock.

ResolveFlag#enforce! now takes the flag owner's row lock right after the content's, before any read of the reports table. A second escalation about the same person waits before it touches that table. This stays within the gem's lock order (flag, content, person, report).

I deliberately added no automatic deadlock retry: it would re-run host hooks such as ban_handler. Two concurrent escalations about unrelated content and people can still, rarely, deadlock on MySQL. The database then rolls one back whole, nothing is applied, and its caller gets ActiveRecord::Deadlocked to retry, as with any Rails app on InnoDB.

The version goes to 1.0.0.beta4, with Gemfile.lock re-locked so CI's frozen install sees it.

Third commit, from a confirming review. There is now one lock order everywhere: flag, then content, then person, then report. It is documented once, on Moderate.with_row_lock.

• Flag.flag_for_review! used to lock the content and then the waiting flag, the reverse of a flag decision, so a review and an enforcement of the same content could deadlock on any database. It now takes the content's lock only and reads the waiting flag with a plain read under it. That lock already serializes reviews of the same content.
• Only a decision that can ban takes the person's lock. Removal-only enforcement never touches the account's row.
• New race tests in lock_order_race_test.rb force each interleaving with test-only gates. Both orders of arrival deadlock on 76c9836, and the removal-only case blocks there; all three pass now.

Tests

• The existing race tests in test/services/moderate/escalation_race_test.rb are the regression tests; they failed on MySQL.
• Local runs are green: SQLite, PostgreSQL 16, and the Rails 7.1, 7.2 and 8.1 appraisals on both.
• MySQL is verified by this PR's CI: the mysql (3.4) job passed three consecutive runs on 90d32f3, with 350 runs and 0 skips each, so the race tests run there.

🤖 Generated with Claude Code