Ability to wait for async abort algorithms? #1389

Activity

1. annevk commented on Jul 15, 2025

   

   annevk

   on Jul 15, 2025

   Last edited by annevk

   Member

   More actions

   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?
2. annevk

   added

   addition/proposalNew features or enhancementsNew features or enhancements

   topic: abortingAbortController and AbortSignalAbortController and AbortSignal

   on Jul 15, 2025
3. saschanaz commented on Jul 15, 2025

   

   saschanaz

   on Jul 15, 2025

   Last edited by saschanaz

   MemberAuthor

   More actions

   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 🤦🏻‍♀️
4. annevk commented on Jul 15, 2025

   

   annevk

   on Jul 15, 2025

   Member

   More actions

   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.
5. saschanaz commented on Jul 15, 2025

   

   saschanaz

   on Jul 15, 2025

   MemberAuthor

   More actions

   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()