Every other enum-like setting that can drift across releases (callNoiseSuppression, callDenoiseModel, ringtoneId, translateTargetLang) is explicitly whitelisted/coerced back to a safe default inside getSettings(). seasonalThemeOverride is not: {...defaultSettings, ...saved} passes through whatever string was persisted verbatim. Since resolveSeasonTheme (seasonSchedule.ts:106-110) returns any non-'auto'/'off' override value as-is, and buildOverlayContent's switch falls through to default: return null for anything unrecognized, a persisted theme id that's ever renamed or removed from the union would silently render nothing, while SEASONAL_OPTIONS in the settings UI would no longer have a matching entry to show as selected — a UI/stored-state disagreement with no obvious explanation to the user.
How to trigger
Not currently reproducible against the present code (all persisted values are still valid) — would only manifest after a future release renames/drops a theme id while a user has it pinned. Reported as tech-debt/latent risk, not an active bug.
Suggested fix
Add the same kind of whitelist coercion used for ringtoneId/callDenoiseModel, falling back to 'auto' for any value outside the current seasonalThemeOverride union.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** low · **Type:** tech-debt · **Confidence:** medium
**Location:** `src/app/state/settings.ts:379-430` (`getSettings`)
### Problem
Every other enum-like setting that can drift across releases (`callNoiseSuppression`, `callDenoiseModel`, `ringtoneId`, `translateTargetLang`) is explicitly whitelisted/coerced back to a safe default inside `getSettings()`. `seasonalThemeOverride` is not: `{...defaultSettings, ...saved}` passes through whatever string was persisted verbatim. Since `resolveSeasonTheme` (`seasonSchedule.ts:106-110`) returns any non-`'auto'`/`'off'` override value as-is, and `buildOverlayContent`'s `switch` falls through to `default: return null` for anything unrecognized, a persisted theme id that's ever renamed or removed from the union would silently render nothing, while `SEASONAL_OPTIONS` in the settings UI would no longer have a matching entry to show as selected — a UI/stored-state disagreement with no obvious explanation to the user.
### How to trigger
Not currently reproducible against the present code (all persisted values are still valid) — would only manifest after a future release renames/drops a theme id while a user has it pinned. Reported as tech-debt/latent risk, not an active bug.
### Suggested fix
Add the same kind of whitelist coercion used for `ringtoneId`/`callDenoiseModel`, falling back to `'auto'` for any value outside the current `seasonalThemeOverride` union.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:51:27 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: low · Type: tech-debt · Confidence: medium
Location:
src/app/state/settings.ts:379-430(getSettings)Problem
Every other enum-like setting that can drift across releases (
callNoiseSuppression,callDenoiseModel,ringtoneId,translateTargetLang) is explicitly whitelisted/coerced back to a safe default insidegetSettings().seasonalThemeOverrideis not:{...defaultSettings, ...saved}passes through whatever string was persisted verbatim. SinceresolveSeasonTheme(seasonSchedule.ts:106-110) returns any non-'auto'/'off'override value as-is, andbuildOverlayContent'sswitchfalls through todefault: return nullfor anything unrecognized, a persisted theme id that's ever renamed or removed from the union would silently render nothing, whileSEASONAL_OPTIONSin the settings UI would no longer have a matching entry to show as selected — a UI/stored-state disagreement with no obvious explanation to the user.How to trigger
Not currently reproducible against the present code (all persisted values are still valid) — would only manifest after a future release renames/drops a theme id while a user has it pinned. Reported as tech-debt/latent risk, not an active bug.
Suggested fix
Add the same kind of whitelist coercion used for
ringtoneId/callDenoiseModel, falling back to'auto'for any value outside the currentseasonalThemeOverrideunion.Filed from the September 2026 client audit (branch
lotus@4bea4895).