🎨 Pattern: How to protect frontend state from autoFlashState IndexedDB ...

Date: 2026-02-20
Time: 21:39:55 UTC
Session: gspace1-129.9
Agent: storage
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How to protect frontend state from autoFlashState IndexedDB race conditions?

Task: Protect backend session data from autoFlashState overwrites

🎯 Decision Made

Chosen:

Store authoritative data in a separate plain Angular signal() that autoFlashState cannot overwrite

Options Considered:

1. Fix autoFlashState internals
2. Abandon autoFlashState entirely
3. Separate signal for authoritative data (chosen)
4. Use BehaviorSubject instead

💭 Reasoning

autoFlashState has an internal hydration watcher (polling every 50ms) and a loadStateFromStorage Promise that can both fire after your code has already updated the signal with fresh data. When they resolve, they overwrite the signal with stale IndexedDB data. No amount of effects, guards, or timing workarounds in consumer code can fix this because the race is inside autoFlashState itself. The pattern: use autoFlashState for non-critical local cache, but store authoritative data (from backend/API) in a separate signal(). Computed properties merge both sources with the authoritative signal taking priority. Example: sessionHistory merges { ...localState.sessions, ...backendSessions } where backendSessions is a plain signal.

📁 Files Involved

• libs/libs-ai/panel-intelligence/src/lib/services/panel-session-persistence.service.ts
• libs/libs-foundational/storage-system/src/flash/helpers/auto-flash-state.ts

🔗 Related

• Decision ID: dev_1771623595729_6j7lprq
• Session: 129
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation