This repository was archived by the owner on May 20, 2026. It is now read-only.
nes: fix: use speculativeRequestDelay for cached speculative results#4985
Merged
Conversation
When a speculative request completes and its result is cached before the user accepts, the subsequent getNextEdit() takes the cache path where isFromSpeculativeRequest stays false. This causes computeMinimumResponseDelay to use the normal cacheDelay instead of the speculative-specific speculativeRequestDelay (typically 0ms). The test sets cacheDelay=5000ms and speculativeRequestDelay=0ms, then verifies that a cached speculative result returns fast. Currently it times out at 5000ms, confirming the bug.
When a speculative request completes and caches its result before the user accepts, the subsequent getNextEdit() takes the cache path. In this path, isFromSpeculativeRequest was not being set from the cached edit's source, causing computeMinimumResponseDelay to apply the normal cacheDelay instead of the speculative-specific speculativeRequestDelay. Set isFromSpeculativeRequest from cachedEdit.source.isSpeculative in the cache path so that cached speculative results use the correct (typically 0ms) delay.
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes NES minimum-response-delay selection for cached results that originally came from speculative requests, so cached speculative suggestions use InlineEditsSpeculativeRequestDelay (typically 0ms) instead of the normal InlineEditsCacheDelay.
Changes:
- Set
isFromSpeculativeRequestfromcachedEdit.source.isSpeculativein the cached-edit path socomputeMinimumResponseDelay()selects the correct delay bucket. - Add a regression test ensuring cached speculative results honor
speculativeRequestDelayeven whenenforceCacheDelay=true.
Show a summary per file
| File | Description |
|---|---|
| src/extension/inlineEdits/node/nextEditProvider.ts | Propagates speculative-origin metadata when serving from cache so delay computation uses the speculative-specific delay. |
| src/extension/inlineEdits/test/node/nextEditProviderSpeculative.spec.ts | Adds coverage for the “speculative completed → cached → served from cache” path to prevent regressions. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 0
justschen
approved these changes
Apr 5, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
When a speculative request completes and caches its result before the user accepts, the subsequent getNextEdit() takes the cache path. In this path, isFromSpeculativeRequest was not being set from the cached edit's source, causing computeMinimumResponseDelay to apply the normal cacheDelay instead of the speculative-specific speculativeRequestDelay.
Set isFromSpeculativeRequest from cachedEdit.source.isSpeculative in the cache path so that cached speculative results use the correct (typically 0ms) delay.