Re: [whatwg/streams] Add a flag to determine wether a ReadableStream is disturbed or cancelled (#1025)

It is cursed practice to produce cheating solutions. And TBH it's just strange to see proposals like this in a standard development body. WhatWG shouldn't lower the bar for itself. This behavior is decreasing reliability of Web Platform by several points and WhatWG IMO should earn points not to spend them. Transparent and sustainable standards are WhatWG's KPI and quality metrics. 

Fetch and Stream APIs have been developed by WhatWG, but somehow become inconsistent and now require to be fixed. They throw errors in browsers and these errors aren't fully catchable due to web platform error messages fragmentation. Also there is some kind of undefined behavior in the current Stream design. Now it about to bring fragmentation into Node.js and embeddable solutions. And it will be hard to get rid of it. 

There are several solutions which are properly developed, have better maintenance and could fix the issue:

1. Add a flag to Stream instance.
2. Add `fetch.canConsumeStream()` method.
3. Create DisturbedStream error.
4. Change Fetch API. 

## 1. Add a flag to Stream instance

It's one of core feature for consequential data streams, to provide information about own state. And it should work like this:

1. Developer checks stream's state with a flag `!stream.disturbed && !stream.locked`.
2. Claim ownership with `stream.getReader()` or pass a stream into synchronous function which claims ownership.
3. Start consuming data from a stream.

Such solution is universal and solve all possible errors and brings freedom to developers to implement any kind of behavior. Without such flag there is undefined state presented.

### Pros
1. Solves the issue with O(1) complexity as: `!stream.isDisturbed`.
2. Solve undefined state issues.

### Cons
1. Requires standard modification.

## 2. Add `fetch.canConsumeStream()` method.

This os ok. In the case if the Fetch API won't change its behavior and will be the only API which requires disturbed flag. But in the case there will be more APIs which will use disturbed flag, there will be more such methods.

It's required for many APIs: web request and response handling, file reading and writing, video and audio processing.
So it's crucial to implement the first option. 

### Pros
1. Solves the issue with O(1) complexity as: `fetch.canConsume(stream)`.

### Cons
1. May require duplicate methods in other APIs in the future.

## 3. Create DisturbedStream error.

It solves potential errors in the future and lets platforms to decide how to implement Fetch API and wether to rely on disturbed flag or not. And let developers to handle the error with simplicity by its name.

### Pros
1. Solves the issue with O(1) complexity with:
    ```js
        try {
           const req = new Request(url, {body: stream})
           // ...
        } catch (err) {
          if (err.name === 'DisturbedStream') {
            // ...
          }
       }
    ```
### Cons

1. Wordy and more resource-consuming.

## 4. Change Fetch API.

It won't be a breaking change, if Fetch API would start to accept disturbed streams. So in the case if such behavior is admissible, then this is the better option and the most simple solution for now.

### Pros

1. Easy to implement.
2. Reduces ambiguity and difference in behavior.

### Cons

1. Doesn't seems to be proper in case of consequential streams.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1025#issuecomment-945809897