perf(home): read recent-meeting metadata from a SQLite index, not file re-parse#1329
Draft
r3dbars wants to merge 2 commits into
Draft
perf(home): read recent-meeting metadata from a SQLite index, not file re-parse#1329r3dbars wants to merge 2 commits into
r3dbars wants to merge 2 commits into
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…e re-parse The Home capture list re-parsed each visible meeting transcript (full Markdown read + frontmatter parse + speaker-label regex + summary parse) on every refresh, which does not scale to a large library. Add `RecentMeetingMetadataCache`, a small SQLite-backed index keyed by transcript path and validated by the transcript + summary-sidecar modification time and size. `RecentMeetingsScanner.loadRecent` now serves a warm row straight from the index with no transcript content read; on a miss or when the on-disk file changed it parses as before and repopulates the index. Retained-audio attachments are still resolved live each refresh (a cheap directory probe with its own invalidation path), so behavior is identical to the file-scan path. The cache degrades safely to the old cold-parse behavior if SQLite fails to open or a payload fails to encode/decode. Test: warm the index, chmod the transcript unreadable, and prove the row still loads (impossible if it re-read the file), plus a control showing the unreadable file yields no row when the index is cold, and an invalidation test showing a changed transcript re-parses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The Home capture list (
RecentMeetingsScanner.loadRecent) re-parsed each visible meeting transcript on every refresh — full Markdown read + frontmatter parse + speaker-label regex + summary parse — which doesn't scale to a large library (NEXT_WORK #10).This points the Home list at an index: a small SQLite cache (
RecentMeetingMetadataCache) keyed by transcript path and validated by the transcript + summary-sidecar modification time and size (cheapstats, no content reads). On a warm hit the row is rebuilt straight from the index and no transcript content is read; on a miss or when the on-disk file changed it parses exactly as before and repopulates the index.Why a new cache instead of an existing table
The Home row needs the summary preview, speaker-needs-review count, and audio-health hint — none of which the existing
StatsDatabase.recordingstable or the MCPTranscriptIndex(separate package, JSON-indexed, not app-linked) store. A pure "read the existing table" swap would drop fields and break the behavior-identical requirement. So this caches exactly the derived row, keyed by file identity, and falls back to the live parse whenever the file changes.Scope / honesty
limitrows (it breaks early), so this removes those per-row content reads/parses. The O(N) directorystatenumeration (needed for ordering + cache validation) is unchanged. A fully index-orderedORDER BY date DESC LIMIT nquery that skips the directory entirely would need an authoritative, save-path-synced index + migration — out of scope here and a bigger conflict surface.HomeCaptureRefreshObserver).Test
Tests/RecentCaptureScannersTests.swift:chmod 000the transcript, prove the row still loads with identical fields (impossible if it re-read the file), plus a control showing the unreadable file yields no row when the index is cold.Verification
bash build.sh --no-open✅bash run-tests.sh✅ (10167 passed)bash run-e2e-smoke.sh✅ (added the new file to its swiftc source list)Manual proof (Home feels fast with a big library) is for Justin.
Conflict note
Touches
RecentCaptureScanners.swift(data-source swap only) — kept deliberately narrow to coexist with the in-flight UI-polish PRs that also touch Home. No Home view changes.🤖 Generated with Claude Code