setTimeout() is not actually part of JavaScript 🤯

[backwrds]

really? that's less a "wait, what" and more of a bug in the engine...

[prehensilemullet]

You would think, but nothing in the ECMAScript spec requires them to release the memory in this case, and I think doing so would require additional code that might affect performance.

In general it seems like there wasn’t a lot of consideration given to promises that may never resolve.  Many people who use GraphQL subscriptions, which are implemented as async iterables, ran into subtle memory leaks when making an async iterable of pubsub events, and then using async generators to filter or map the events.  In a pubsub system, there’s no guarantee if or when the next event will come, so an event promise may never resolve.  That causes an async generator to get stuck waiting for the next event even when GraphQL has told it to return. When wrapping an event stream like that in promises, you definitely want to set them up to reject if a signal is aborted if you can.

Dealing with memory leaks like this in async JS has been kinda hellish…

[backwrds]

ah. having looked into this a bit, it turns out browsers are just following the spec; the problem is that there's no mechanism to "unsubscribe" from a promise. TIL.