Windows: app exits silently at startup — splash 15s auto-close races slow gateway readiness (browser probe close takes ~15s on some machines)

[linjicong]

Summary

On Windows, the app often exits silently during startup (no error dialog, no log entry) because of a race condition: the startup splash window auto-closes after a fixed 15 seconds, but the managed agent-gateway child service can take longer than 15 s to become ready. When the splash closes and no main window has been created yet, Electron fires window-all-closed and the app calls app.quit(), so the user sees "click icon → nothing happens".

Observed on Memmy 1.1.1 Windows x64 (cn edition). Reinstalling does not fix it.

Environment

• OS: Windows 11 Home China 10.0.26200
• App: Memmy 1.1.1, install dir D:\software\Memmy, runtime home D:\MemmyData\.memmy (external data layout)
• Machine also runs 4 security products (360, Tencent PC Manager, Lenovo/Huorong, Defender) — likely why Chromium graceful shutdown is slow here

Reproduction

1. Cold start (no leftover gateway from a previous crashed instance), e.g. after reboot.
2. Splash "正在启动…" shows for exactly 15 s, then the process exits silently. startup.log records boot:start but never boot:ready.
3. Repeat attempts fail the same way. Occasionally a launch succeeds if a gateway orphan from the previous failed instance is still alive (the desktop then adopts the external gateway instantly).

Measured on this machine (manual spawn of the gateway child with the same args/env as the desktop):

+2.4s   [migration] migration_deferred { migrationId: 'v1.0.7/0002-import-legacy-app-state-model-config', scope: 'runtime-config' }
+3.7s   4 chrome.exe probe processes appear (memmy-browser-probe-* in %TEMP%)
        ...15 s of silence...
+18.8s  "memmy gateway started (websocket)"   ← ready only after ~19 s

With tools.browser.enabled: false the same gateway is ready in 2.6 s.

Root cause chain

1. gateway startup runs initializeLoopRuntimeTools() → BrowserSessionManager.probe() which launches a headless Chromium (managed chromium-1232) and then closes it.
2. In probe()'s finally block, await browser.close() is a graceful Chromium shutdown. On this machine a graceful close takes ~15 s, while killing the browser process externally (taskkill /F) makes close() return in 71 ms. So the delay is Chromium's graceful shutdown, not launch.
3. Gateway readiness is therefore ~19 s > splash lifetime.
4. SPLASH_MAX_VISIBLE_MS = 15 * 1000 (dist/main/main.js) closes the splash; since the main window hasn't been created yet, window-all-closed fires and the app quits with exit code 0 — no boot:error, no crash dump, no console output.

Exit-code evidence: launching the app and waiting returns ExitCode = 0; stderr shows only benign libpng warnings.

Workaround (verified)

Setting tools.browser.enabled: false in %MEMMY_HOME%\config.yaml (i.e. D:\MemmyData\.memmy\config.yaml) skips the Chromium probe; the app then boots to boot:ready in ~5 s consistently.

Suggested fixes (any of these would have saved hours of debugging)

1. Don't quit on window-all-closed while boot is still in progress (isBootReady === false), or keep the splash alive until the main window is created instead of using a fixed 15 s timer.
2. Time out / await-parallelize the browser probe during gateway startup (it's only a capability probe; a slow Chromium shouldn't block readiness), or skip the probe when browser-preparation-state.json is already ready and freshly verified.
3. Write a diagnostic line to startup.log before the splash auto-close decision, e.g. boot:waiting-gateway, so future reports don't require inspector-level debugging.

Happy to provide additional traces (CPU profile of the gateway startup, before-quit stack) if useful.

[linjicong]

Follow-up: 1.1.2 upgrade breaks memory service startup — legacy migration crashes on UNIQUE constraint

After upgrading 1.1.2 (cn edition), the app shows "memory layer network error" because the managed memory service fails to install/start. The bundled memory CLI (resources/memory-runtime/dist/src/cli/index.js install --service-only) exits with code 1:

UNIQUE constraint failed: trace_policy_links.l1_memory_id, trace_policy_links.l2_memory_id, trace_policy_links.relation

Mechanism (in dist/src/cli/legacy-migration.js): when importing the legacy local-plugin database (.dsh/memos-plugin/data/memos.db in my case, 1578 trace_policy_links rows), multiple legacy traces with identical content are merged into one target memories row (the sameMemory dedup path in mapAndInsert). But each merged trace's link to the same policy is still inserted, producing duplicate (l1_memory_id, l2_memory_id, relation) triples that violate the table's UNIQUE constraint (schema.js:346). The transaction rolls back, so the ledger stays empty and every install retries the same crash. The migration target is the real 1.1.1-era memory.sqlite, so this blocks the memory service for anyone with legacy plugin data — it is not recoverable by reinstalling.

Workaround applied (local patch to insertRow/mapAndInsert in legacy-migration.js): before inserting into trace_policy_links, check whether the triple already exists; if so, map the source ID to the existing row's ID, record it in legacy_migration_ledger as deduplicated, and continue. With that patch the install completes in ~15 s and imports 2720 L1 + 117 L2 memories and 1563 links (15 collapsed duplicates) with zero constraint violations.

Suggested upstream fix: same idea — dedupe link triples after memory merging (or use INSERT OR IGNORE + ledger lookup for link tables specifically). Happy to share the exact patch diff if useful.