- Shipped
- July 16, 2026 at 5:58 PM UTC
- Author
- Kamo
- Commit
- a9a6652
Per-member UI preferences (nav layout, hex-head sizes, etc.) are stored one row per (member_id, pref_key) in MEMBER_UI_PREFERENCES, guarded by the unique constraint UK_MEMBER_UI_PREF_KEY. "Reset to Standard" soft-deletes the nav layout (DELETE -> is_active=false) but leaves the row occupying that key. **************** looked the row up with the active-only finder, missed the lingering inactive row, built a brand-new row and INSERTed it -> duplicate-key violation on UK_MEMBER_UI_PREF_KEY -> HTTP 500. The kamo-internal frontend swallows the 500 (optimistic .catch()), so the member's reordered nav appeared to save in-session but never persisted, and every login reset to the Standard layout. navLayout was the only pref hitting this because it is the only key with a Reset -> DELETE path. Fix: look the row up by its natural key regardless of is_active (new SecurityService-local **************** so upsert resurrects and reactivates the soft-deleted row (UPDATE by PK) rather than INSERTing a colliding duplicate. Reads (list/get) intentionally stay active-only. Members already stuck self-heal on their next reorder. No schema/shared-lib change; SecurityService redeploy only.