fix: detect newly created files in @ recommendations with core optimizations

[prassamin]

fix: detect newly created files in @ recommendations with core optimizations

This PR addresses issue #24729, where the Gemini CLI was unable to detect new files created during a session in the @ file recommendation menu.

The Problem

The useAtCompletion hook initialized the file searcher only once per session/root-change. Combined with an aggressive 30-second crawler cache, newly created files were not surfaced to the user without a full CLI restart.

The Solution

• CLI Refresh: Updated useAtCompletion to re-initialize searchers every time the @ menu is activated.
• Improved Latency: Lowered the crawler cache TTL to 1 second specifically for the @ menu, ensuring near-instant discovery of new files while maintaining performance.
• Core Optimization: Added a referential equality check in RecursiveFileSearch.initialize() to skip expensive FZF re-indexing if the file list is cached and hasn't changed. This keeps the menu fast even in projects with 100k+ files.
• Verification:
  • Added an integration test in useAtCompletion.test.ts(CLI).
  • Added a unit test in fileSearch.test.ts (Core).

Fixes #24729

[gemini-code-assist]

Warning

Gemini encountered an error creating the summary. You can try again by commenting /gemini summary.

[prassamin]

/gemini summary

[gemini-code-assist]

Summary of Changes

This pull request resolves an issue where the Gemini CLI failed to detect newly created files within the @ file recommendation menu. By adjusting the initialization lifecycle and cache settings, the system now ensures that the file list is refreshed appropriately upon menu activation. Additionally, a performance optimization was introduced to prevent redundant re-indexing of large file sets, maintaining responsiveness even in extensive projects.

Highlights

• CLI Refresh Mechanism: Updated the useAtCompletion hook to re-initialize file searchers whenever the @ menu is activated, ensuring newly created files are detected.
• Optimized Cache TTL: Reduced the crawler cache TTL to 1 second specifically for the @ menu to enable near-instant file discovery without sacrificing performance.
• Core Performance Optimization: Implemented a referential equality check in RecursiveFileSearch.initialize() to skip expensive FZF re-indexing when the file list remains unchanged.

Activity

• Pull request created by prassamin.
• Gemini code assist encountered an error generating the initial summary.
• Author requested a summary via /gemini summary.

[prassamin]

@gemini-code-assist review

[gemini-code-assist]

Code Review

This pull request improves the responsiveness of the file suggestion system in the @ completion menu. It reduces the cache TTL from 30 seconds to 1 second and ensures that the file searcher is re-initialized when the menu is re-opened, allowing it to pick up new files. Additionally, an optimization was implemented in the core file search logic to skip rebuilding the search index if the file list has not changed. I have no feedback to provide as no review comments were submitted.

[wissamblue69-dotcom]

fix: detect newly created files in @ recommendations with core optimizations

This PR addresses issue #24729, where the Gemini CLI was unable to detect new files created during a session in the @ file recommendation menu.

The Problem

The useAtCompletion hook initialized the file searcher only once per session/root-change. Combined with an aggressive 30-second crawler cache, newly created files were not surfaced to the user without a full CLI restart.

The Solution

• CLI Refresh: Updated useAtCompletion to re-initialize searchers every time the @ menu is activated.
• Improved Latency: Lowered the crawler cache TTL to 1 second specifically for the @ menu, ensuring near-instant discovery of new files while maintaining performance.
• Core Optimization: Added a referential equality check in RecursiveFileSearch.initialize() to skip expensive FZF re-indexing if the file list is cached and hasn't changed. This keeps the menu fast even in projects with 100k+ files.
• Verification:
  • Added an integration test in useAtCompletion.test.ts(CLI).
  • Added a unit test in fileSearch.test.ts (Core).

Fixes #24729

[prassamin]

@jacob314 bro, please review my pr!

[prassamin]

@gemini-code-assist review

[gemini-code-assist]

Code Review

This pull request enhances the file search mechanism by introducing an InitializationState enum to manage concurrency and adding an optimization to skip re-indexing when the file list is referentially identical. It also reduces the cache TTL for completions and includes new test cases. Feedback focuses on improving the robustness of concurrent initialization by ensuring multiple callers can await the same promise and correctly caching searcher instances in the useAtCompletion hook to prevent redundant initializations.

[prassamin]

@gemini-code-assist review

[gemini-code-assist]

Code Review

This pull request improves the file search mechanism for the @ completion menu by reducing the cache TTL to 5 seconds and implementing a state machine to manage concurrent initializations. It also adds an optimization to skip rebuilding the search index when the file list remains unchanged. A review comment suggests simplifying the asynchronous initialization logic by relying on the explicit state variable and removing unnecessary fallback checks when a promise is already in progress.

[gemini-code-assist]

When managing the state of asynchronous operations, rely on the explicit state variable initializationState rather than checking for the existence of the initPromise object. Promise objects may be cleared in finally blocks upon completion, making them unreliable for state checks. The logic should ensure that if the state is Initializing, the initPromise is returned directly without fallback checks, as the state enum should be the single source of truth for the operation's status.

Suggested change

	return this.initPromise || Promise.resolve();
	return this.initPromise!;

References

1. When managing the state of asynchronous operations, rely on an explicit state variable (e.g., a state enum) rather than checking for the existence of a promise object. Promise objects may be cleared in finally blocks upon completion, making them unreliable for state checks after the operation has finished.