Ability to wait for async abort algorithms?

[saschanaz]

What is the issue with the DOM Standard?

Currently it's not straightforward to track whether all abort algorithms are finished. You would call AbortController.abort and then would hope it that things are aborted, before starting anything new. It's okay to do so when the new job never clashes with the previous supposed-to-be-aborted job (like some simple fetch() calls), but might clash if the abort algorithm includes closing a file handle, etc.

Would be nice if abort event had something like ExtendableEvent.waitUntil.

[annevk]

Isn't this tracked by the thing you are aborting? It should return an AbortError at some point.

Also, if this is proposing something new, any reason to not follow the template?

[saschanaz]

Isn't this tracked by the thing you are aborting?

Perhaps? But that means "the thing" can't purely use AbortSignal internally but need to implement something else, if "the thing" is also aborting its downstream.

any reason to not follow the template?

Selected a wrong template 🤦🏻‍♀️

[annevk]

I suppose. If you define async getData that takes a signal. And internally it uses async getDataInternal that also takes a signal. It could pass the outer signal to getDataInternal and await getDataInternal to see if it gets an AbortError or some kind of success and based on that decide to return or throw for getData. It's a choice of course whether it wants to wait for getDataInternal, but there's nothing we can really do about that I think.

[saschanaz]

Hmm, I was thinking more about addEventListener-ish "keep working until you get the abort signal" situation. Suppose something like:

while (!signal.aborted) {
  await write(serialize(data), { signal })
  await flush();
  sleep(10000)
}

And then somewhere else you do:

1. Abort the file write repeat
2. Upload the file

At step 2 you don't know whether the last write is flushed or not, because abort() doesn't wait for anything. (in this specific case you can probably call flush() again to make sure, though.)

What would be nicer (while the API addition is arbitrary and probably not nice enough)

while (!signal.aborted) {
  signal.cleanup(() => flush());
  await write(serialize(data), { signal })
  sleep(10000)
}

// And then somewhere else:
// makes sure everything is aborted
await controller.abort()