[Cache Components] Prevent streaming fetch calls from hanging in dev#89171
Merged
unstubbable merged 2 commits intocanaryfrom Jan 28, 2026
Merged
[Cache Components] Prevent streaming fetch calls from hanging in dev#89171unstubbable merged 2 commits intocanaryfrom
unstubbable merged 2 commits intocanaryfrom
Conversation
6f4ccda to
27910fe
Compare
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
27910fe to
41b1402
Compare
Collaborator
Tests Passed |
41b1402 to
bc21670
Compare
28d5658 to
99e7bfa
Compare
Merging this PR will not alter performance
Comparing 
Footnotes
|
99e7bfa to
e731c0b
Compare
bc21670 to
7fa7f13
Compare
Collaborator
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles: **432 kB** → **432 kB** ✅ -42 B81 files with content-based hashes (individual files not comparable between builds) Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (8 files)Files with changes:
View diffsapp-route-ex..ntime.dev.jsDiff too large to display app-route-ex..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route.runtime.dev.jsDiff too large to display app-route.ru..time.prod.jsDiff too large to display |
7fa7f13 to
f578636
Compare
e731c0b to
11e2950
Compare
f578636 to
b6bcd91
Compare
With Cache Components enabled in development, fetches without an explicit cache config were incorrectly routed through `createCachedPrerenderResponse` during the cache filling phase due to the `serverComponentsHmrCache` condition. This function awaits the entire response before returning to the caller, which prevents infinitely streaming responses from ever being read or aborted. This is a regression that was introduced in #84088. These fetches should be treated as dynamic and use `createCachedDynamicResponse` instead, which returns immediately and caches in the background with proper error handling. The fix adds `isCacheableRevalidate` to the condition so only explicitly cacheable fetches use the blocking path. Additionally, the "Failed to set fetch cache" warning is now suppressed when the request's abort signal was triggered, since aborting is intentional.
b6bcd91 to
d9c7cf3
Compare
devjiwonchoi
approved these changes
Jan 28, 2026
unstubbable
added a commit
that referenced
this pull request
Jan 28, 2026
…89171) With Cache Components enabled in development, fetches without an explicit cache config were incorrectly routed through `createCachedPrerenderResponse` during the cache filling phase due to the `serverComponentsHmrCache` condition. This function awaits the entire response before returning to the caller, which prevents infinitely streaming responses from ever being read or aborted. This is a regression that was introduced in #84088. These fetches should be treated as dynamic and use `createCachedDynamicResponse` instead, which returns immediately and caches in the background with proper error handling. The fix adds `isCacheableRevalidate` to the condition so only explicitly cacheable fetches use the blocking path. Additionally, the "Failed to set fetch cache" warning is now suppressed when the request's abort signal was triggered, since aborting is intentional.
unstubbable
added a commit
that referenced
this pull request
Jan 29, 2026
…89171) With Cache Components enabled in development, fetches without an explicit cache config were incorrectly routed through `createCachedPrerenderResponse` during the cache filling phase due to the `serverComponentsHmrCache` condition. This function awaits the entire response before returning to the caller, which prevents infinitely streaming responses from ever being read or aborted. This is a regression that was introduced in #84088. These fetches should be treated as dynamic and use `createCachedDynamicResponse` instead, which returns immediately and caches in the background with proper error handling. The fix adds `isCacheableRevalidate` to the condition so only explicitly cacheable fetches use the blocking path. Additionally, the "Failed to set fetch cache" warning is now suppressed when the request's abort signal was triggered, since aborting is intentional.
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.
3 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.
With Cache Components enabled in development, fetches without an explicit cache config were incorrectly routed through
createCachedPrerenderResponseduring the cache filling phase due to theserverComponentsHmrCachecondition. This function awaits the entire response before returning to the caller, which prevents infinitely streaming responses from ever being read or aborted.This is a regression that was introduced in #84088.
These fetches should be treated as dynamic and use
createCachedDynamicResponseinstead, which returns immediately and caches in the background with proper error handling. The fix addsisCacheableRevalidateto the condition so only explicitly cacheable fetches use the blocking path.Additionally, the "Failed to set fetch cache" warning is now suppressed when the request's abort signal was triggered, since aborting is intentional.