Reduce memory usage for large clipboard histories - #49
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d863f34d05
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| private func contentVersionKey(_ item: ClipItem) -> String { | ||
| contentDigest(item) |
There was a problem hiding this comment.
Preserve legacy version keys in published checkpoints
When a 1.7.0–1.7.3 device shares iCloud data with this version, checkpoints now contain only digest-keyed historyVersions, while those older clients look up the legacy txt:/img:/... key and fall back to item.createdAt. If that older device already recorded a later metadata update for the same content, it rejects a newer title or metadata edit from the checkpoint as stale; after compaction deletes the covering batch and the device records the checkpoint as applied, the edit remains permanently missing even after upgrade. Keep legacy keys in the interoperable checkpoint format, or version the format and teach old/new readers how to preserve the actual record timestamp.
AGENTS.md reference: AGENTS.md:L92-L93
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 501957f4a5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ), mappedBytes != MAP_FAILED else { | ||
| return nil |
There was a problem hiding this comment.
Reset failed index builds before retrying search
When a large or unlimited history causes this new mmap allocation to return MAP_FAILED, the build task resolves to nil, but scheduleSearchIndexBuild clears searchIndexTask only after a successful build. Consequently, ensureSearchIndex() keeps awaiting the same completed nil-valued task for every subsequent non-empty query, leaving the full unfiltered history visible until the user clears search long enough for eviction or the history changes. Clear the failed task or provide a fallback so later queries can retry.
Useful? React with 👍 / 👎.
Summary
Validation