From a183a4f5124d5dc32849852e532987f5be72b88b Mon Sep 17 00:00:00 2001 From: Paul Hitt Date: Sat, 26 Sep 2026 14:39:00 -0400 Subject: [PATCH] Self-hosting: the one manual step older SQLite relays need Relay finding F10 fixed the email-verification migration on SQLite. It was meant to mark every existing account verified and, because SQLite has no NOW(), marked nobody without raising an error. The fix only reaches relays that have not run that migration yet, since a migration runs once. The by-hand repair for the rest was written down only in a relay commit message, which is not somewhere a self-hoster looks. It is on the page now, under Updating. The UPDATE marks only accounts created before the migration ran, read from the migration's own row in _fluent_migrations, so anyone who signed up since still has to confirm their address, and it is safe to run twice or on a relay that never needed it. The relay renders this page and runs the SQL exactly as printed against a database left in the broken state, so the two cannot drift apart. Co-Authored-By: Claude Opus 5.5 --- SELF-HOSTING.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/SELF-HOSTING.md b/SELF-HOSTING.md index bdd90d6..6bd2a6e 100644 --- a/SELF-HOSTING.md +++ b/SELF-HOSTING.md @@ -202,6 +202,36 @@ relay reads an older database and brings it forward. Take a dump first anyway, not true, and an older relay against a newer database is not a supported direction. +### One step by hand for older SQLite relays + +This is for a relay on SQLite (no `FN_POSTGRES_URL`) that was already running +before 25 September 2026. Postgres relays can skip it, and so can a SQLite relay +first started after that date. + +When email verification was added, the upgrade was meant to mark every account +that already existed as verified, so that switching verification on later +would lock nobody out. On SQLite that step failed without an error and marked +nobody. Nothing changes until you set `FN_EMAIL_VERIFICATION_REQUIRED`. Once +you do, everyone who signed up before that upgrade is turned away and asked for +a code from an email that was never sent. + +The relay now does this correctly, but each upgrade step runs once, and a relay +that already ran the broken one will not run it again. Stop the relay, copy +`relay.sqlite` somewhere safe (it is wherever `FN_DB` points, if you set it), +open it with `sqlite3 relay.sqlite`, and run: + +```sql +UPDATE users SET email_verified_at = CURRENT_TIMESTAMP +WHERE email_verified_at IS NULL + AND (created_at IS NULL OR created_at <= ( + SELECT created_at FROM _fluent_migrations + WHERE name = 'FlamenetRelay.AddEmailVerification')); +``` + +It marks only the accounts that existed before verification arrived. Anyone +who signed up since still has to confirm their address. Running it a second +time, or on a relay that never needed it, changes nothing. + ## Telling your users about updates The Android app asks *your* relay whether a newer build exists, not an address -- 2.54.0