fix(field): keep every value in the FIELD suggestion cache

[chhoumann]

A {{FIELD}} prompt now offers the same values every time it opens. Before, the second and later prompts offered only the first 1,000 values the scan found.

Cause

FieldSuggestionCache.set copied at most MAX_VALUES_PER_ENTRY (1,000) values into the cache entry. collectFieldValuesCached returns the full scan on a miss and the cut-down copy on every hit, so the list shrank from the second prompt on, until a note changed and cleared the cache. The cap came with the cache in #826.

The cache already holds at most 100 entries, one per field and filter set, and drops them on any note change, after 5 minutes, or with fieldSuggestions.clearCache(). This removes only the per-entry cap.

Measured

Obsidian 1.13.7, isolated vault with 20,151 notes; aliases has 26,668 distinct values. A Capture with format {{FIELD:aliases}}, run twice after a note change, typing alias 1999:

	First prompt	Second prompt
master	Ada alias 19996, Alan alias 19992, Vint alias 19999, ...	only alias 1999 (the typed text)
This branch	Ada alias 19996, Alan alias 19992, Vint alias 19999, ...	the same rows

The prompt opens in 61-87 ms either way.

In the one-page form's FIELD input, which asks the cache on every keystroke, master was fast (about 18 ms a keystroke) because from the second keystroke it searched 1,000 values. Typing ada alias 19 there now takes 51-114 ms a keystroke (median 70-88 ms) for this 26,668-value field, and shows 200 matches instead of 10. Almost all of it is sorting and de-duplicating the values again on each keystroke (FieldValueProcessor.processValues), which the cache doesn't keep. A field with 400 values (owner) stays at about 18 ms. Caching the processed list instead of the raw set would remove that cost; I left it out to keep this to the bug.

Tests

• FieldValueCollector.issue2108.test.ts: 1,500 notes with distinct author values; the second collectFieldValuesProcessed call returns all 1,500, the same as the first. On master it returns 1,000.
• pnpm run build-with-lint, pnpm run test (6600 passed), .agents/run-e2e (395 passed, 24 Templater-only skipped).

Release / migration

None. Pre-existing since #826, not a 2.30.0 regression.

Fixes #2108

Note

Fix FieldSuggestionCache.set to store all values, not just the first 1,000

Removes the per-entry 1,000-value cap in FieldSuggestionCache.ts. Cache-key creation, entry-count eviction, and timestamps are unchanged. Adds a regression test in FieldValueCollector.issue2108.test.ts that collects 1,500 distinct values twice and checks both results are complete and equal. Risk: cached sets for fields with many values now grow without a bound; check memory usage for large vaults.

📊 Macroscope summarized a1cda57. 1 file reviewed, 1 issue evaluated, 0 issues filtered, 1 comment posted

🗂️ Filtered Issues

Summary by CodeRabbit

• Bug Fixes
  • Field suggestions now retain all collected values instead of stopping at 1,000. The cache still limits the number of stored entries.
  • Added regression coverage for collecting and retrieving 1,500 values across multiple calls.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: cf8eff95-b7d9-491e-b0af-2d7c5a6bd58b

📥 Commits

Reviewing files that changed from the base of the PR and between fcb315d and a1cda57.

📒 Files selected for processing (2)

• src/utils/FieldSuggestionCache.ts
• src/utils/FieldValueCollector.issue2108.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 5 remain after this review.

---

📝 Walkthrough

Walkthrough

FieldSuggestionCache now stores all supplied field values instead of limiting each entry to 1,000. A regression test checks that collecting 1,500 distinct values returns the same complete set on a second call.

Changes

Field suggestion cache

Layer / File(s)	Summary
Store complete field-value sets src/utils/FieldSuggestionCache.ts, src/utils/FieldValueCollector.issue2108.test.ts	The cache stores a copy of all supplied values and retains its existing oldest-entry eviction. The regression test checks that two collection calls return the same 1,500 values.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to a1cda

The change fixes missing suggestions on later prompt openings. No merge-blocking issue remains; larger fields retain the acknowledged processing overhead.

Security Architecture Review

Security architecture risk: 🔵 Low · up to a1cda

The fix preserves complete suggestions and existing invalidation controls. Large fields can now consume more retained memory and processing time on repeated prompts. No new privilege or data-access boundary was identified, but exposure to malicious vault data is not established.

Retained concerns

• Low · reliability · inferred: Removing the per-entry cardinality bound increases retained allocations and repeated copying and processing for large fields. The remaining entry-count and expiration controls do not bound aggregate cached values or per-refresh work. This weakens local host availability containment; malicious exploitation would require influence over vault data and a way to trigger FIELD suggestion collection, neither of which is established for an external attacker.

Security review details

Security Blast Radius

• inferred — The demonstrated resource amplification affects the plugin's shared cache and suggestion processing within the hosting Obsidian process. Exposure scales with distinct values and populated field/filter combinations, up to 100 retained entries; entry count alone is not a memory budget. A broader service or tenant exposure is not established.

Security Findings and Attack Paths

• inferred — A conditional availability path runs from high-cardinality vault field data through complete cached Sets, defensive copies, and repeated suggestion processing. Exploitation would require data influence and collection invocation. The existing miss path already returned complete values, so the introduced amplification is retention and repeat-hit work, not a new full-vault scan or verified remote attack path.

Trust Boundaries and Controls

• observed — The assessed change preserves filter-specific cache identity, defensive ownership, and revision-guarded insertion. No added identity or privilege transition appears in the changed setter or its collector path.

Resilience and Maintainability Implications

• observed — The input consumer limits ranked display results only after complete collection and processing. That display limit therefore does not contain the increased upstream allocation and processing work.

Hardening Proposals

• proposed — Consider a value-count or memory-aware admission budget that skips caching oversized sets without truncating returned suggestions. This could preserve completeness while limiting retained-cache amplification; it would not independently bound full-scan or processing work.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: retaining every value in the FIELD suggestion cache.
Linked Issues check	✅ Passed	The change satisfies issue [#2108]. FieldSuggestionCache.set now stores new Set(values) without the 1,000-value truncation. A regression test scans 1,500 distinct author values and verifies that…
Out of Scope Changes check	✅ Passed	The pull request changes only the FIELD suggestion cache behavior and adds a regression test for issue [#2108]. The cache-entry limit and existing eviction behavior remain unchanged. No unrelated chan…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit gathers fields in a row
No thousand-value fence to slow
One thousand five hundred hop inside
Then back again, the same whole stride
The cache keeps every name in view
And rabbits nibble carrots, too}

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-01T10:40:55.632780Z	a1cda57	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.