mesalogo
b90ff50f2a
Load Supervisor graphs only when opened, preserve source details on demand, reuse indexed story digests and window selection lists without losing keyboard or focus behavior. Route heavy UI reads through the existing worker, batch scoped queries and construct each publication snapshot once. Keep remote cancellation responsive during model-route cleanup, remove late routes and retain reported usage after response-cap cancellation. Preserve Telegram pending replies through polling conflicts, show delivery errors and honor the final rate-limit cooldown. Schema 62 adds lookup indexes without rewriting user content; older clients cannot open upgraded data. Large review publication still blocks Main and remains documented follow-up work. Record the future storage-service direction without performing the architecture migration. Validation: exact staged code passed isolated full tests (6212 passed, 87 skipped), typecheck and lint. Three-round source performance comparisons, SQLite migration equivalence, native Electron interaction checks and current-source Linux x64 Host validation completed; eight external text-model requests. Release note: Supervisor opens reviews without loading the entire graph, keeps long selection lists responsive and preserves details and keyboard navigation. Remote cancellation and Telegram reply recovery are more reliable; remote fixes require an Agent build containing this change.
4.4 KiB
Desktop Storage Direction
Status and scope
2026-10-05: proposed target for the remaining PERF-15/PERF-16 work. The user has requested documentation first, followed by bounded local fixes and a commit. The full storage-service migration remains a separate discussion after those fixes. Current desktop storage still has Main-owned business writes and selected worker reads; this document does not describe a completed migration.
Target responsibilities
- Renderer owns presentation, domain stores and disposable visible-data caches. It consumes summaries, pages and incremental notifications, not full database copies.
- Electron Main owns windows, trusted IPC, credentials, OS integration and service lifecycle. Heavy SQL, JSON assembly and document processing execute elsewhere.
- A desktop storage utility process would own business database connections and complete domain transactions. Retain the existing database files, schemas and durability distinctions. One write owner per database does not require merging databases.
- Existing read-only workers can serve heavy queries under the storage service's lifecycle. Do not place every read and write behind one long-running global job.
- Parsing, OCR, model inference and Runtime execution remain separate workloads. Remote Agent databases remain remote; desktop persistence acknowledges remote events only after the required local commit succeeds.
The service boundary consists of domain operations such as publishing a review or committing an event batch. Do not expose arbitrary SQL, transport transaction callbacks, or split an atomic transaction across individual IPC calls. Synchronous SQLite inside its dedicated execution environment can remain appropriate.
Correctness and lifecycle
Preserve write-before-read ordering, result/checkpoint atomicity, cancellation settlement, event deduplication and commit-before-ACK. A rejected caller Promise does not establish that a writer stopped. Reuse existing operation IDs and unique constraints to resolve uncertain outcomes; do not blindly replay mutations or add a general recovery journal.
Open business connections after required upgrades. Stop producers before draining required writes and closing storage. A failed storage process must not silently fall back to Main SQL or an empty persistent-data replacement. Keep bounded requests and explicit failure/retry behavior without adding product approval gates.
VS Code comparison
VS Code is a reference for service separation, asynchronous work, lazy activation,
cached UI state and shutdown coordination, not a requirement to copy its process map.
Its application/profile/workspace state connections are owned by Electron Main;
the backend uses asynchronous @vscode/sqlite3, while cached reads are synchronous
and writes are batched. GoodBuddy's relational history, source bodies and durable
remote-event acknowledgements require different payload and persistence boundaries.
Sources reviewed on 2026-10-05 (upstream main, not a pinned performance comparison):
Current implementation boundary
The immediate work reuses existing workers, narrows Supervisor loading and payloads, optimizes measured queries, virtualizes lists, and removes repeated digest/snapshot work. It does not add the utility process, convert every storage interface, or claim exclusive ownership of assistant.sqlite. Read-only workers plus remaining Main writes are an explicit transition state.
Full migration should proceed through verified domain operations and converge by database ownership. Do not leave undocumented competing write paths. Completion requires no Main-owned desktop business SQL, transactions wholly inside the owner, responsive reads/writes under heavy work, and validated startup/cancellation/shutdown.
The local implementation record owns this round's scope and measurements. The performance principles remain the acceptance criteria; regression ceilings are not equivalent to those budgets.