At least this stackoverflow answer suggests the handlers are GC’ed: https://stackoverflow.com/questions/79448475/are-promise-han...

The original promise needs to reference the chained promise, not the other way round.

As jobs complete I would expect the top of the chain to be eligible to be garbage collected.

  a = b.then(c);

(If the runtime maintains async stack traces, that could be an issue...but that is a common issue, and the stack depth is limited.)

    await job1()
    await job2()
    await job3()
    await job4()

Modern frontend development performance best practise is to allow for garbage collection only when the browser crashes.

Even if you are doing `then().then()`, something _else_ in the code base could retain the promise somehow and then your whole chain isn't GCable!

For example https://github.com/rxaviers/async-pool library that implements concurrency for async iterators (and uses promise.race) subtly creates GC pressure which you dont see until you make a whole lot of calls and suddenly its slow

https://github.com/tc39/proposal-type-annotations

I wonder why are you downvoted for being as factual and neutral as it is technically possible.

It creates 1 object allocation per enqueue.

`prom.then(fn)` creates a new promise. The new promise’s resolver function is the `fn` inside `then(fn)`, and the new promise’s asynchronous computation is the original promise’s resolver function.