[whatwg/fetch] "consume body" step disagrees with "fully read" on whether the error callback accepts an argument (Issue #1636)

I've noticed what I think is an inconsistency while implementing part of Fetch.

First, the definition for ["fully read a body"](https://fetch.spec.whatwg.org/commit-snapshots/8f109835dcff90d19caed4b551a0da32d9d0f57e/#ref-for-byte-sequence⑨) says:

> processBodyError must be an algorithm accepting no arguments\. 

However, ["consume a body"](https://fetch.spec.whatwg.org/commit-snapshots/8f109835dcff90d19caed4b551a0da32d9d0f57e/#concept-body-package-data
) then passes an algorithm that accepts an error argument as `processBodyError`, here named `errorSteps`:

> 3. Let errorSteps given error be to reject promise with error\.

> 6. Otherwise, fully read object’s body given successSteps, errorSteps, and object’s relevant global object\. 

Other places that call "fully read a body" that I've come across all pass it an algorithm that does not accept arguments.

We had previously implemented `processBodyError` as taking a single argument, and then the algorithms for it just ignore that argument, but this is problematic when that code also needs to be run separately when no argument is provided. (eg, ["main fetch" step 22](https://fetch.spec.whatwg.org/commit-snapshots/8f109835dcff90d19caed4b551a0da32d9d0f57e/#ref-for-concept-request-integrity-metadataâ‘ ) both calls `processBodyError` without arguments in step 22.2 and passes it to "fully read a body" in step 22.4.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1636
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1636@github.com>