fix(settings): prevent null localStorage values from overriding state defaults#815
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #815 +/- ##
==========================================
- Coverage 30.76% 30.71% -0.05%
==========================================
Files 33 33
Lines 1973 1976 +3
Branches 368 366 -2
==========================================
Hits 607 607
+ Misses 1345 1290 -55
- Partials 21 79 +58 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Greptile SummaryThis PR fixes a regression where
Confidence Score: 5/5Safe to merge — the change is a well-scoped fix to the settings load path with no new external dependencies and no changes to save/persist logic. The two-pass merge correctly prioritises server settings, then guards against both JS-null and string-"null" localStorage values before applying existing JSON parsing and type coercion. Behaviour for all valid stored values is unchanged, and the cleanCategory transform and isJsonKey list are preserved without alteration. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[load settings] --> B[get_settings from server]
B --> C{for each server key}
C -->|starts with underscore| D[skip]
C -->|valid key| E[store server value, mark as used]
E --> F{for each localStorage key}
F -->|starts with underscore or already used| G[skip]
F -->|valid key| H[raw = localStorage.getItem]
H --> I{raw is null or string null}
I -->|yes| J[skip, keep state default]
I -->|no| K{isJsonKey?}
K -->|yes| L[JSON.parse, cleanCategory if classes]
K -->|boolean string| M[parse as boolean]
K -->|other| N[store raw string]
L --> O[patch store with merged storage]
M --> O
N --> O
Reviews (2): Last reviewed commit: "fix(settings): guard against string "nul..." | Re-trigger Greptile |
The previous null guard (raw === null) only catches the case where
localStorage.getItem returns JS null (key not present). Since the loop
iterates Object.keys(localStorage), every key already exists — raw is
never JS null here.
The actual root cause: an older AW version (or third-party code) calling
localStorage.setItem('views', null) stores the string "null". For JSON
keys, JSON.parse("null") evaluates to JS null, which then overrides the
defaultViews state() default with null.
Fix: also skip raw === 'null' to preserve state() defaults for any key
whose localStorage value is the null sentinel string.
|
@greptileai review |
|
Ready to merge — all CI green, Greptile 5/5 (safe to merge), review thread resolved. |
Fixes #813
When localStorage contains keys with
nullvalues (keys present but not set by this app),localStorage.getItem(key)returns the string"null"which then overrides the sane defaults defined in the Piniastate()function.Root cause: The old code merged all localStorage keys (including garbage/null ones) with server keys, then applied all of them with ``. A key present in localStorage with a
nullvalue would overwrite the default.Fix: Two-part change:
nullreturn values fromlocalStorage.getItem— if a key producesnull, it genuinely doesn't exist and thestate()default should be preserved.Verification: The
views/settings-load flow that triggers the TypeError on Activity page now starts from correct defaults instead of receivingnull. Manual testing on a fresh AW instance with empty/no settings should show the Activity page loading without errors.