Skip to content

Centralize app persistence in SQLite and harden state/event flows - #86

Merged
juliusmarminge merged 1 commit into
codething/48364d50from
codething/142d0619
Feb 21, 2026
Merged

Centralize app persistence in SQLite and harden state/event flows#86
juliusmarminge merged 1 commit into
codething/48364d50from
codething/142d0619

Add durable provider event catch-up by sequence

f8aadcf
Select commit
Loading
Failed to load commit list.
MacroscopeApp / Macroscope - Correctness Check completed Feb 21, 2026 in 4m 15s

2 issues identified (17 code objects reviewed).

• Merge Base: b9bb89c
• Head: f8aadcf

Details

✅ File Path Comments Posted
✅ apps/server/src/persistenceService.ts 0
✅ apps/server/src/wsServer.ts 0
❌ apps/web/src/routes/__root.tsx 2
✅ apps/web/src/wsNativeApi.ts 0
✅ packages/contracts/src/ipc.ts 0
✅ packages/contracts/src/provider.ts 0

Filtered Issues Details

apps/server/src/wsServer.ts
  • line 338: The WS_METHODS.providersCatchUp handler in wsServer.ts calls persistenceService.providerCatchUp using user-controlled parameters (request.params). The underlying providerCatchUp implementation in persistenceService.ts (visible in the provided diff/references) uses the limit parameter directly in a SQL LIMIT clause and loads all resulting rows into memory using .all(). Because there is no server-side upper bound enforcement on limit in the shown code, a client can send a very large number (or -1 for all rows), causing the server to attempt to load an unbounded number of events into memory. This creates a high-risk Out-Of-Memory (OOM) vector reachable via the WebSocket API. [ Already posted ]
View more details on MacroscopeApp