Startup is blocked by full vault index refresh before workspace tabs can paint

[junereycasuga]

Description

When opening ZenNotes on a vault with many notes, the previously-open tabs take a few seconds to appear. The window chrome and app shell render quickly, but the tab strip/editor surface stays blank until the full vault scan finishes.

Root cause

packages/app-core/src/store.ts restores the workspace in this order during init():

1. refreshVaultIndexes() — walks the vault and streams all note metadata.
2. prefetchInitialVisibleNotes() — preloads the visible note list.
3. restoreWorkspaceForVault() — finally reads the saved workspace snapshot and sets workspaceRestored = true.

Because restoreWorkspaceForVault validates tab paths against the complete notes index, it cannot paint the saved tabs until the entire vault listing is done. On large vaults that listing alone takes seconds, so the user sees an empty workspace for that whole time.

What should happen

The saved workspace snapshot is tiny compared to the notes index. The tab layout and active-tab paths should be restored immediately from the snapshot, and the full note index should refresh in the background. Missing/stale tabs can be pruned once the index arrives.

[adibhanna]

Thanks for the writeup, and for tracing it all the way into store.ts: your root-cause read was exactly right. init() (and every vault-switch flow) awaited the full refreshVaultIndexes() before restoreWorkspaceForVault(), and the restore validated saved tab paths against the complete notes index, so nothing could paint until the whole vault had been listed.

Fixed on the v2.27.0 branch in 989b2ec, following the shape you suggested:

• The saved workspace snapshot is restored first and trusted: the tab layout and active panes paint immediately, and the active tabs' contents are read straight from disk (a failed read drops that tab on the spot).
• The full index refresh then runs after the workspace is already up. Once the listing arrives, tabs whose notes no longer exist are pruned (the same reconciliation that already guarded mid-session refreshes), folder rows come up collapsed per the usual startup rule, and background tabs get their content warm-up.
• Until metadata arrives, tab titles fall back to the filename, then upgrade in place.

Measured over CDP against the built app with a seeded 3000-note vault and a saved 3-tab workspace: before, tabs painted about 100ms after the listing was applied; after, they paint about 300ms before it, with the editor already showing the active note. The lead grows with vault size, since the scan no longer sits between launch and first paint.

How to test locally once it ships (or from the branch):

1. Build and launch: npm run build, then open a vault with a few thousand notes and several tabs open.
2. Quit and relaunch.
3. Before: window chrome appears, then the tab strip and editor stay blank until the vault scan finishes. After: your tabs and the active note appear immediately, and the note list fills in as the scan completes.

This will ship in the next release. Leaving the issue open until then.

[adibhanna]

Closing as fixed by 989b2ec on the v2.27.0 branch; it ships with the 2.27.0 release. Details and local test steps are in the comment above.