guanghu/docs/adr/0124-cached-secondary-note-window-startup.md
冰朔 8739805f99
Some checks failed
Auto-update PR branches / Update open PR branches (push) Has been cancelled
CI / Frontend Static Quality Checks (push) Has been cancelled
CI / Frontend Tests & Coverage (push) Has been cancelled
CI / Rust Tests & Quality Checks (push) Has been cancelled
CI / Linux build verification (push) Has been cancelled
Release (Alpha) / Compute alpha version (push) Has been cancelled
Release (Alpha) / Build release artifacts (push) Has been cancelled
Release (Alpha) / GitHub Release (alpha) (push) Has been cancelled
Release (Alpha) / Update docs and release pages (push) Has been cancelled
Deploy docs / Build VitePress site (push) Has been cancelled
Deploy docs / Deploy to GitHub Pages (push) Has been cancelled
光湖开源源码快照 · Tolaria AGPL 分叉基线 · 独立更新链
2026-07-05 17:45:16 +08:00

1.4 KiB

type, id, title, status, date, supersedes
type id title status date supersedes
ADR 0124 Cached secondary note window startup active 2026-05-26 0123

Context

ADR-0123 restored secondary note windows to the normal App path so they retain the full vault/workspace graph required by Properties, quick open/search, wikilinks, and workspace-aware note actions.

That parity is still the product contract, but forcing a fresh Tauri reload_vault during every secondary-window mount invalidates the backend cache. Opening several note windows can therefore repeat expensive full-vault scans even when the main window has already warmed the cache.

Decision

Secondary note windows keep the full vault graph, but their initial vault load uses the cached/incremental list_vault path instead of the forced reload_vault path.

Normal main-window startup continues to force a fresh initial reload. Explicit refresh paths, watcher-driven refreshes, and user-initiated reloads still use reload commands where they need disk freshness.

Consequences

  • Secondary note windows remain capable full app windows rather than reduced editor shells.
  • Repeated note-window opens can reuse the backend vault cache instead of invalidating it on every startup.
  • First open after a cold cache still scans the vault, then warms the shared backend cache for later windows.
  • If the cached scan path is stale, the existing backend cache update logic remains responsible for incremental freshness.