Open
Conversation
* fix: reserve folder budget in initial context command cap The initial sendContextCommands push is capped at 1000 items, but the flat slice(0, 1000) starves folders when files dominate the list. In large repos (212k+ items), the first 1000 are almost all files, so @folder shows no children until the user types a search term. Partition items by type and reserve 10% of the cap budget for folders before filling the rest with files and code symbols. This ensures @folder always has children on first load. The filter handler already searches the full uncapped cache, so this only affects the initial push. * test: add folder budget tests for processContextCommandUpdate Verify that the initial context command cap reserves slots for folders: - folders are included when items exceed the cap - all folders included when fewer than budget - total items don't exceed CONTEXT_COMMAND_PAYLOAD_CAP - small payloads pass through unchanged * fix: apply cap to empty-search filter response to preserve @folder When onFilterContextCommands fires with an empty searchTerm (user navigated back or cleared search), the handler was returning ALL cached items (212k+) with no cap. This massive response overwrote the tab's contextCommands store, and subsequent @folder clicks showed an empty list because the store structure was inconsistent. Apply the same cap+budget logic as processContextCommandUpdate so the empty-search response matches the initial push structure. * refactor: remove stale context command cache, always pull fresh from indexer The cachedContextCommands field was a separate copy of the indexer's data that could get out of sync — causing @folder to show empty after searches overwrote the store, and stale items to persist after file operations. Remove the cache entirely. The indexer (local-indexing) is the single source of truth. The filter handler now calls getFreshItems() on every request, and processContextCommandUpdate receives items directly from the indexer callbacks. The cap+budget logic is extracted into capItems() and shared between the initial push and the empty-search filter path. * fix: restore base context commands on empty filter instead of round-tripping After a search filtered the context commands, the store held the filtered set. Subsequent @Folder/@file clicks read from this stale store and showed only the previous search results. When onContextCommandFilter fires with an empty searchTerm (user cleared search or navigated back), restore contextCommandGroups directly to the store instead of sending a request to the server. This keeps the store consistent with the base set and avoids the round-trip latency. * fix: prevent sendContextCommands from resetting active filter tab sendContextCommands is a server push that fires on indexing changes and overwrites contextCommands for ALL tabs. This reset the picker while the user was browsing @Folder/@file sub-menus, causing the 6-10 second snap-back to the main menu. Skip the store update for tabs with an active filter session (lastFilterTabId). Clear the guard on tab change, tab remove, and chat prompt submission so it doesn't persist. * fix: restore base contextCommands after filter response via microtask filterContextCommandsResponse updates the store with filtered results so the picker's store listener can refresh. But this left the store with stale filtered data, causing @Folder/@file to show previous search results on subsequent navigation. After updating the store for the picker, schedule a microtask to restore contextCommandGroups (the base set) back to the store. The picker captures filtered items synchronously during updateStore, so the microtask restore doesn't affect the current display but ensures sub-menu navigation reads from the full base set. * fix: restore filterContextCommandsResponse store update Now that mynah-ui preserves baseContextCommands separately from the store's contextCommands, the filter response can safely update the store again. The picker uses the filtered data for display while sub-menu navigation reads from the base snapshot. * chore: patch * test: cover getFreshItems and registerFilterHandler empty-search - 3 tests for getFreshItems: getInstance reject, getContextCommandItems reject, success path. - 2 tests for registerFilterHandler empty-search path: applies capItems folder budget when called with empty searchTerm and when called with a whitespace-only searchTerm. * fix: reserve code symbol budget in capItems The previous capItems partitioned items into folders vs nonFolders, where nonFolders included both files AND code symbols sharing the same 900-slot budget. In file-heavy repos (e.g. Linux kernel: 212k+ items) files dominate the input order so code symbols are silently dropped from the initial picker view, even though typing a search term still finds them via the non-empty filter path. Replace the 2-way partition with a 3-way 10/10/80 split (folders / code / files). Slack from an under-filled folder or code budget flows into the file budget via the subtraction below. Mirrors the existing folder-budget fix pattern. Add 5 tests: - code symbols included when items exceed cap - all code symbols preserved when fewer than budget - 100/100/800 split when all three categories overflow - code not starved when files come first in input (regression case) - empty-search filter handler also reserves the code budget * fix: bump context command payload cap from 1000 to 2000 Double both CONTEXT_COMMAND_PAYLOAD_CAP and MAX_FILTER_RESULTS so the initial picker view and the typed-search filter response can return up to 2000 items each. The 10/10/80 budget split now yields 200 folders / 200 code / 1600 files instead of 100 / 100 / 800. The bottleneck under load is fs.existsSync over the full ~212k indexer item set, not the cap; doubling the cap adds <50KB to the LSP payload and a few ms to map/render but is otherwise negligible. mynah-ui's DetailedListWrapper virtualizes by visible block, so 2x items don't add proportional render cost. Update all 8 affected test assertions to the new expected counts. * chore: bump @aws/mynah-ui to ^4.40.1 Pulls in the latest mynah-ui patch release. See https://github.com/aws/mynah-ui/releases/tag/v4.40.1 * fix: switch capItems split to 500/500/1000 (25/25/50) Folders and code symbols each get 25% of the cap (500), files get 50% (1000). Previously the 10/10/80 split (200/200/1600) tilted heavily toward files; the new split gives folders and code symbols a fair share of the initial picker view in folder- and symbol-rich repos. This only affects the **empty-search** picker view (no search term). The non-empty filter path still scores against the full fresh indexer set in registerFilterHandler — typing a search term will find any folder, file, or code symbol regardless of whether it fit into the cap. Test inputs scaled up to 600-800 per category so the new 500-slot budget is actually exercised. All 24 tests pass. * test: drop stale cachedContextCommands assertion in preservation test The property-based test 'processContextCommandUpdate sends all items and caches them for small payloads' has been failing in CI since commit 79e6e75 (refactor: remove stale context command cache, always pull fresh from indexer). That refactor deleted the cachedContextCommands field, but this preservation test still asserted that (provider as any).cachedContextCommands === items, which now always evaluates to undefined !== items and fails on the empty-array counterexample. Drop the cache assertion. The test now verifies the still-meaningful contract: processContextCommandUpdate dispatches exactly one sendContextCommands call with a contextCommandGroups payload. Local repro: npx mocha --require ts-node/register 'src/language-server/agenticChat/context/contextCommandsProvider*.test.ts' → 28 passing.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2694 +/- ##
==========================================
+ Coverage 60.50% 60.53% +0.03%
==========================================
Files 279 279
Lines 66468 66502 +34
Branches 4264 4272 +8
==========================================
+ Hits 40217 40260 +43
+ Misses 26166 26157 -9
Partials 85 85
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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
2 participants
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.
Problem
Solution
This merges the released changes for 1.64.0 into main.
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.