On a fresh database every Settings save fails with
Unit Of Lpg: Invalid option: expected one of "liter"|"gallon"|"kilogram"|"pound"
even though the user never touched the LPG unit. The seeded value is itself invalid, so the page is blocked until the value is corrected by hand.
Repro: fresh DB → sign up → Settings → change anything (e.g. theme) → Update Settings.
Cause: 20260120190820_config_changes.sql seeds unitOfLpg = 'litre', but settings-form.helper.ts declares z.enum(['liter','gallon','kilogram','pound']). unitOfVolume is seeded as 'liter' in 20250918173510_update_configs.sql, so this looks like a one-off inconsistency rather than a convention.
Existing installs that already ran the migration keep the bad value, so a seed correction alone won't heal them — a follow-up migration is needed for those.
I have a fix ready and tested against fresh and already-migrated databases (disclaimer: heavily assisted by Claude on coding and review); happy to open a PR, or leave it with you.
One question first: it corrects the seed in the original migration and adds a healing migration. Editing an applied migration is safe with the libsql migrator (it selects pending work by journal timestamp, not file hash), but if you'd rather never touch a shipped migration I can put everything in the new one instead.
On a fresh database every Settings save fails with
even though the user never touched the LPG unit. The seeded value is itself invalid, so the page is blocked until the value is corrected by hand.
Repro: fresh DB → sign up → Settings → change anything (e.g. theme) → Update Settings.
Cause:
20260120190820_config_changes.sqlseedsunitOfLpg = 'litre', butsettings-form.helper.tsdeclaresz.enum(['liter','gallon','kilogram','pound']).unitOfVolumeis seeded as'liter'in20250918173510_update_configs.sql, so this looks like a one-off inconsistency rather than a convention.Existing installs that already ran the migration keep the bad value, so a seed correction alone won't heal them — a follow-up migration is needed for those.
I have a fix ready and tested against fresh and already-migrated databases (disclaimer: heavily assisted by Claude on coding and review); happy to open a PR, or leave it with you.
One question first: it corrects the seed in the original migration and adds a healing migration. Editing an applied migration is safe with the
libsqlmigrator (it selects pending work by journal timestamp, not file hash), but if you'd rather never touch a shipped migration I can put everything in the new one instead.