Bugfix: What real bugs and performance issues exist in the storage-s...

Documentation for Sessions

🐛 Bugfix: What real bugs and performance issues exist in the storage-s...

Date: 2026-03-03
Time: 18:40:33 UTC
Session: gspace1-166.11
Agent: storage
Confidence: 95%
Status: ✅ Documented


📋 Decision Context

Question:

What real bugs and performance issues exist in the storage-system after Session 166.3, and how to fix them?

Task: Session 170: Storage system P0-P2 bug fixes and performance improvements


🎯 Decision Made

Chosen:

Fixed 6 issues (2 P0, 2 P1, 2 P2): (P0) Replaced setInterval(50ms) hydration polling with Angular effect() — eliminates memory leak and CPU waste. (P0) Wired broadcastMigration() into createPersistentSignal migration flow — cross-tab migration coordination was dead code, now actually broadcasts. (P1) Replaced JSON.stringify change detection with monotonic version counter — O(1) instead of O(n) for large states. (P1) Added sweepExpiredStates() for TTL enforcement — autoFlashState TTL option was decorative, now enforceable. (P2) Added batch drain to BackendSyncEngine via toBatchPayload — groups items by descriptor for single HTTP call. (P2) Added onSyncDropped callback to SyncDescriptor — permanent failures now notify consumers instead of silent discard.

Options Considered:


💭 Reasoning

P0 bugs: setInterval was a genuine memory leak (never cleared if hydration fails) + broadcastMigration was dead code (built in 166.3 but never called). P1 perf: JSON.stringify on every signal emission is O(n) serialization — for chat states with 100+ messages this is measurably slow. Version counter is O(1). TTL was listed as a feature in docs/API but never enforced — misleading. P2 UX: batch drain reduces N HTTP calls to 1 for same-descriptor items; onSyncDropped prevents silent data loss after permanent failures.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation