Lots of `Unhandled Promise Rejection: Abort Error: Fetch is aborted` error is being displayed in console, when network is disconnected while data from `ReadableStream` is being read. The sample code below will abort stream data reading after 1 second. Chrome browser does not throw an error and ends stream reading gracefully, however Safari and WkWebView threw lots of error in console. -- ``` const url = 'https://...'; // URL which takes more than 1 second to download function test(url) { const abortController = new AbortController(); window.setTimeout(() => { abortController.abort(); }, 1000); window.fetch(url, { signal: abortController.signal }).then(response => { const reader = response.body.getReader(); reader.read().then(function processData({ value, done}) { if (done) { return; } return reader.read().then(processData); }) .catch(error => console.error('reader error handled gracefully', error)); }); } test(url); ```
This line of the code seems throwing those errors. https://github.com/WebKit/webkit/blob/950143da027e80924b4bb86defa8a3f21fd3fb1e/Source/WebCore/Modules/streams/ReadableStreamInternals.js#L302 I guess there are lots of internal requests being queued to buffer incoming data for efficient reading. Those requests being cancelled should not be revealed to consumer in console pane.
Right, we should add @promiseFlagsIsHandled to the promises. In general, we should update the ReadableStream implementation up to spec.
<rdar://problem/68082772>
This is a problem in Mapbox-GL-JS that is being faced by a number of users of the library. Reference: https://github.com/mapbox/mapbox-gl-js/issues/8480 Whether using a nested promise or a chained promise, this error is logged to the console when a fetch request is cancelled while reading the response data. Link to the code in question: https://github.com/mapbox/mapbox-gl-js/blob/0102e52123fc66df98853620ced6e0e3195fa9a4/src/util/ajax.js#L144-L157 This problem affects our customers who are using logged errors for production applications, and have to handle a large number of these spurious errors.
Any update on this? I opened a new ticket to bump up this issue as it seems to be a continued problem: https://bugs.webkit.org/show_bug.cgi?id=249784 Thanks!
*** Bug 249784 has been marked as a duplicate of this bug. ***
I cannot reproduce with the snippet, closing as configuration changed. I'll fix https://bugs.webkit.org/show_bug.cgi?id=251463 which is still an issue.