You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we have now half duplex streaming uploads should there also be a test where the AbortController gets aborted after the call to fetch? The asserts should still be the same right?
assert_equals(cancelReason,fetchErr,"Fetch rejects with same error instance");
},"Readable stream synchronously cancels with AbortError if aborted before reading");
It looks like browsers don't support the current test as they don't cancel the ReadableStream and cancelReason is not set.
I think the don't even touch the ReadableStream in this case as it isn't locked which I kind of get.
But when an active streaming upload gets cancelled the ReadableStream should always be canceled, as it is locked by the browser.
In addition to only cancel the ReadableStream on abort it would also be useful if the ReadableStream got cancelled when fetch fails due to network issues, cors, HTTP1, or anything else.
Since we have now half duplex streaming uploads should there also be a test where the
AbortController
gets aborted after the call tofetch
? The asserts should still be the same right?wpt/fetch/api/abort/general.any.js
Lines 503 to 537 in e77818a
It looks like browsers don't support the current test as they don't cancel the
ReadableStream
andcancelReason
is not set.I think the don't even touch the
ReadableStream
in this case as it isn't locked which I kind of get.But when an active streaming upload gets cancelled the
ReadableStream
should always be canceled, as it is locked by the browser.See also https://bugs.chromium.org/p/chromium/issues/detail?id=1480250
The text was updated successfully, but these errors were encountered: