Steer is the better default for Enter while an agent is running, but flipping DEFAULT_CLIENT_SETTINGS alone would only reach new installs. Client defaults are materialized into storage — the first load writes the whole default blob and every save re-stamps it — so every existing install already has "interrupt" on disk, and a stored "interrupt" cannot be told apart from one the user actually chose. A one-time migration flips them all; picking "interrupt" afterwards sticks. The applied-migration marker sits in its own storage key rather than in the settings blob: StoredAppSettingsSchema is strict and readValidatedJson clears the value when parsing fails, so an unknown field there would wipe every setting for anyone who downgrades. migrateAppSettings owns both of its writes so the settings blob always lands before the marker. A failed marker write leaves the migration to re-run harmlessly; a failed settings write must leave the marker unwritten, or the migration is lost and the user keeps "interrupt" for good.
14 lines
700 B
TypeScript
14 lines
700 B
TypeScript
/** Storage keys live here so `storage` and `migrations` can share them without importing each other. */
|
|
|
|
export const APP_SETTINGS_KEY = "@paseo:app-settings";
|
|
export const LEGACY_SETTINGS_KEY = "@paseo:settings";
|
|
|
|
/**
|
|
* The applied-migration marker deliberately sits outside the settings blob:
|
|
* `StoredAppSettingsSchema` is a strict object and `readValidatedJson` clears the value when
|
|
* parsing fails, so a new field there would wipe every setting for anyone who downgrades to a
|
|
* client that predates it. Keeping the marker as a list of ids also means the next migration is
|
|
* a new entry rather than a schema change.
|
|
*/
|
|
export const SETTINGS_MIGRATIONS_KEY = "@paseo:settings-migrations";
|