Stop a double-submit from creating duplicate registrations and people

[maebeale]

🤖 suggested review level: 5 Inspect 🔬 concurrency guard (MySQL named lock) + registration-flow change across the public registration path

A registrant who double-clicked Register (or came back and re-submitted) could end up with two people and two registrations for the same event — this closes both the accidental double-click and the underlying race, and stops re-submissions from silently losing earlier answers.

Duplicate registrations from a double-submit

• Client guard: the public registration form now uses the existing submit-once Stimulus controller, so the button locks after the first click. This matters most on paid events, which opt out of Turbo (turbo: false) and so had no submitter disabling at all — the likely source of the "two registrations in the same minute" incident.
• Server backstop: a genuine concurrent submission (two tabs, a proxy retry) still raced find_or_create_person, so the flow now serializes same-identity submissions behind a MySQL named lock (email + last name + event, namespaced by database so parallel test suites don't contend). The second request waits, then matches the first's committed person. Best-effort: a blank identity or an un-acquirable lock falls through rather than failing a real registration.

Re-registration no longer overwrites answers

• A returning registrant reuses their one Person and one event registration, but re-submitting used to overwrite their prior FormSubmission in place, silently dropping the earlier answers. Each submission is now recorded on its own, preserving the full history (the admin registrants view already iterated multiple submissions).
• The public confirmation view defaults to the most recent submission when none is named.

Tests

• Same name + email → one person, one registration, two submissions.
• File-upload specs updated: each submission is independent; the earlier one keeps its file, a blank re-submit adds a fileless submission.
• Confirmation view defaults to the latest submission.
• submit-once renders on free and paid events.
• The identity lock is taken and released around the flow (a true thread race isn't unit-testable without flakiness).

[jmilljr24]

This looks overcomplicated. I thought we just had a conversation about double submits.

[maebeale]

@jmilljr24 happy to have you submit something different

[jmilljr24]

The lock seemed excessive (same point I made when this double submit came up on a different form). The main issue was handle the turbo-false since it disables turbo handling the double submit. This form needs the option to disable turbo for the stripe checkout so the submit-once controller is sufficient for client side. That will catch 99% of the issues. The deduper can handle the rest since is it needed anyway for true duplicate submission since the person matching is pretty loose.