Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the underlying source be pinged for cancel when a close request exists? #1252

Open
saschanaz opened this issue Jan 21, 2023 · 1 comment

Comments

@saschanaz
Copy link
Member

saschanaz commented Jan 21, 2023

const stream = new ReadableStream({
  start(c) {
    c.enqueue(new Uint8Array(8));
    c.close();
  },
  cancel() {
    console.log("cancellation happened");
  }
});
stream.cancel();

This calls the cancel callback, and this does not:

const stream = new ReadableStream({
  start(c) {
    c.enqueue(new Uint8Array(8));
    c.close();
  },
  cancel() {
    console.log("cancellation happened");
  }
});
const reader = stream.getReader();
reader.read();
reader.cancel();

... as ReadableStreamCancel does not check [[closeRequested]] in the first example.

I think the underlying source is effectively done at the point it calls controller.close(), is there a reason it should be pinged for anything after that? Probably too late to change the behavior even if there's no need, though.

@ricea
Copy link
Collaborator

ricea commented Jan 24, 2023

My interpretation is that in the second case, all the data has been read, so the underlying source doesn't need to know about the cancellation. But in the first case there's potentially been some data loss.

It's probably too late to change the behaviour given how much code has been written against the current semantics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants