Skip to content

Conversation

@KhafraDev
Copy link
Member

@KhafraDev KhafraDev commented Nov 3, 2025

fixes #4647

the offending line was added in 9e5316c but I don't see any rationale for why urlList was frozen, the spec doesn't mention freezing the list.

the issue was caused by freezing the list which would prevent us from pushing to it which would swallow the error

@codecov-commenter
Copy link

codecov-commenter commented Nov 3, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.88%. Comparing base (9271564) to head (ae6c648).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4656      +/-   ##
==========================================
+ Coverage   92.84%   92.88%   +0.03%     
==========================================
  Files         106      106              
  Lines       33272    33272              
==========================================
+ Hits        30892    30904      +12     
+ Misses       2380     2368      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@tsctx
Copy link
Member

tsctx commented Nov 3, 2025

I believe it was wrong to classify status 0 as a network error, but I'm unsure which way is correct.

diff --git a/lib/web/fetch/index.js b/lib/web/fetch/index.js
index 0f0a94d3..da58a0dc 100644
--- a/lib/web/fetch/index.js
+++ b/lib/web/fetch/index.js
@@ -646,7 +646,7 @@ async function mainFetch (fetchParams, recursive) {
 
     // 13. If response is not a network error and response is not a filtered
     // response, then:
-    if (response.status !== 0 && !response.internalResponse) {
+    if (response.type !== 'error' && !response.internalResponse) {
       // If request’s response tainting is "cors", then:
       if (request.responseTainting === 'cors') {
         // 1. Let headerNames be the result of extracting header list values
@@ -676,8 +676,7 @@ async function mainFetch (fetchParams, recursive) {
 
     // 14. Let internalResponse be response, if response is a network error,
     // and response’s internal response otherwise.
-    let internalResponse =
-      response.status === 0 ? response : response.internalResponse
+    let internalResponse = response.type === 'error' ? response : (response.internalResponse ?? response)
 
     // 15. If internalResponse’s URL list is empty, then set it to a clone of
     // request’s URL list.
@@ -717,7 +716,7 @@ async function mainFetch (fetchParams, recursive) {
     // set internalResponse’s body to null and disregard any enqueuing toward
     // it (if any).
     if (
-      response.status !== 0 &&
+      response.type !== 'error' &&
       (request.method === 'HEAD' ||
         request.method === 'CONNECT' ||
         nullBodyStatus.includes(internalResponse.status))

@KhafraDev
Copy link
Member Author

both are correct

@KhafraDev
Copy link
Member Author

In other words, an opaque filtered response and an opaque-redirect filtered response are nearly indistinguishable from a network error. When introducing new APIs, do not use the internal response for internal specification algorithms as that will leak information.

A network error is a response whose type is "error", status is 0, status message is the empty byte sequence, header list is « », body is null, and body info is a new response body info.

I did notice what you are saying when working on it, but it's not relevant to the bug so I didn't bother. We are technically detecting network errors incorrectly, but if it's not causing bugs... 🤷

@KhafraDev KhafraDev marked this pull request as ready for review November 3, 2025 20:12
Copy link
Contributor

@Uzlopak Uzlopak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You've got my LGTM

@KhafraDev KhafraDev merged commit 7cc4fcf into nodejs:main Nov 4, 2025
33 of 35 checks passed
@KhafraDev KhafraDev deleted the issue-4647 branch November 4, 2025 01:01
@github-actions github-actions bot mentioned this pull request Jan 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fetch() hangs with redirec and no-cors

5 participants