What happens with rejections in synchronous iterables?

[senocular]

Are synchronous iterables/array-likes being iterated synchronously or asynchronously as they would in a for await? What is the expectation for a rejection within a sync collection that settles before to other promises prior? In a for await it goes unhandled. Would Array.fromAsync() be able to account for that and reject its returned promise or would it to allow for the unhandled rejection to slip through?

const delay = (ms, reject = false) => new Promise((r, j) => setTimeout(reject ? j : r, ms, ms));

for await (let ms of [delay(1000), delay(3000), delay(2000, true)]) {
  console.log(ms) // 1000, (unhandled error 2000), 3000
}

[js-choi]

Good question. The answer should be yes, the input value’s rejection should be captured returned in the returned promise. That is, Array.fromAsync([delay(1000), delay(3000), delay(2000, true)]) should return a promise that will reject. Each item in the sync iterable is sequentially awaited, and the first item that is a rejection will halt the sequential iteration. At this point, all prior promises in the sequence must have had resolved beforehand, because they would have already been awaited, and all following promises in the sequence are ignored.

I believe that the Array.fromAsync specification reflects this desired behavior.
When we supply a non-async-iterable-but-sync-iterable input to Array.fromAsync,
then, within the Abstract Closure (step 3) of an immediately invoked async function’s promise (steps 2 and 4),
Array.fromAsync will create an Async-from-Sync iterator object in step 3.h.
Each item of this Async-from-Sync iterator object will be Awaited in step 3.j.iii.
If an item settles to a rejection, then that Await operation will cause ThrowCompletion to occur in the async context of the immediately invoked async function from step 4 (see steps 5–7 of the Await algorithm).
In that case, the async function’s promise will reject, as per step 4 and as per AsyncBlockStart’s step 3.f.

Hopefully this answer is satisfactory.
I will add a paragraph to the explainer later that clarifies this.

[senocular]

Array.fromAsync will create an Async-from-Sync iterator object in step 3.h.

This is what makes me think it wouldn't handle the rejection. If its iterating through an asynchronous version of the iterator, doesn't it have to wait for the current next value to settle before moving on to the next next value?

In the example array provided, while awaiting delay(3000), delay(2000, true) is going to reject. At this time the loop wouldn't have gotten to that promise to await (step 3.j.iii) because, unless I'm misunderstanding, it wouldn't have called the async iterator's next until delay(3000) resolves.

[js-choi]

I think I see what you mean now. Because delay(2000, true) rejects before Array.fromAsync can Await it, Array.fromAsync is unable to add a rejection handler to delay(2000, true) before it does reject.

However, as you know, Awaiting an already-rejected promise will in turn throw an error in the current async context. So my understanding is that Array.fromAsync should still return a promise that will reject at step 3.j.iii once it does reach delay(2000, true), even if delay(2000, true) already has rejected.

Anyways, I will raise this with the proposal’s reviewers (CC: @ljharb, @nicolo-ribaudo) and see if this is truly a problem and if we need to do anything special about this. I would wish for no unhandled rejection to ever escape this function, but there probably is no way to avoid that with for await sequential-read semantics.

Perhaps it is then a matter of whether those input promises count as being “inside” Array.fromAsync (and handled by that function) rather than “outside” Array.fromAsync; if they don’t count as being “inside”, then no rejection can escape Array.fromAsync, because those input promises were never inside Array.fromAsync in the first place.

I suppose we could adopt Promise.all semantics for sync iterables and synchronously dump sync iterables before immediately awaiting all of them in parallel…but that feels pretty strange to me. My intuition is to match for await and sequentially read values, to match semantics with async iterables.

[ljharb]

I'm a bit confused. You made a rejected promise and didn't handle it. I'd expect an unhandled rejection here, just like in for-of.

[mhofman]

Right, if you generate the promise when consumed by the iterator, it behaves as expected:

const delay = (ms, reject = false) => new Promise((r, j) => setTimeout(reject ? j : r, ms, ms));

function * getIterator (config) {
    for (const item of config) {
        yield delay.apply(null, item);
    }
}

for await (let ms of getIterator([[1000], [3000], [2000, true]])) {
  console.log(ms) // 1000, 3000, (uncaught error 2000)
}

The Async-from-Sync Iterator objects do not eagerly consume the sync iterator. The problem in the original example was that it eagerly created the promises, which included an unhandled rejection.

[senocular]

I'm a bit confused. You made a rejected promise and didn't handle it. I'd expect an unhandled rejection here, just like in for-of.

You can catch this in a normal for...of

for (let promise of [delay(1000), delay(3000), delay(2000, true)]) {
   promise.catch(() => 'handled')
}

Promise.all will also handle it

Promise.all([delay(1000), delay(3000), delay(2000, true)]) // rejects, but not unhandled

for-await...of results in an unhandled because it fails to reach the rejection in time.

So the question is, does fromAsync use Promise.all with sync iterables/array-likes (eager), or does it still for-await...of (lazy)? If an iterable is sync, is it meant to be iterated synchronously, even if it contains async (promise) values? Or is fromAsync going to wait and possibly allow for unhandled rejections? If the latter, I think the "supports sync" of this needs a big asterisk saying something to the effect of "you should probably be using Promise.all() instead"

[mhofman]

You can catch this in a normal for...of

Right, that's because you eagerly (aka synchronously) consume all the promises produced.

If an iterable is sync, is it meant to be iterated synchronously, even if it contains async (promise) values?

A sync iterable means it synchronously produces values, it doesn't mean it eagerly creates them. Why should a consumer of the iterator assume it can eagerly consume these values?

[ljharb]

I would expect that if you did Array.fromAsync([Promise.resolve(), Promise.reject()]) that you'd get an array of two promises, one resolved and one rejected.

The awaiting done here is on the async iteration result, which contains the value but is not itself the value.

[mhofman]

To clarify, fromAsync takes an iterable, it doesn't take an array. That's where the distinction is. There is no way to know from just holding an iterable whether it has eagerly created all its values or not, and the safe thing to do is assume it hasn't.

I also doubt we'd want to brand check the argument to see if the iterable is an array or a generic iterable. Now it's possible a generic utility would be useful to turn an array of promises into an async iterable that handles rejections in the way you expect them. For example it'd attach a .catch to all promises eagerly and recreate a new promise for caught unyielded promised on iterator close.

async function * makeAsyncIteratorFromArray(arr) {
  arr = arr.map((value) => Promise.resolve(value));
  arr.forEach((promise) => promise.catch(() => {}));
  let promise;
  try {
    while(promise = arr.shift()) {
      yield await promise;
    }
  } finally {
    while(promise = arr.shift()) {
      new Promise((r) => r(promise));
    }
  }
}

const delay = (ms, reject = false) => new Promise((r, j) => setTimeout(reject ? j : r, ms, ms));

for await (let ms of makeAsyncIteratorFromArray([delay(1000), delay(3000), delay(2000, true)])) {
  console.log(ms) 
  if (ms === 3000) break;
}
// 1000, 3000, (unhandled rejection 2000)

[ljharb]

We absolutely must not do that - Array.from takes an iterable, or failing that, an arraylike - it never checks or cares if something's an actual Array. Similarly, Array.fromAsync not check or care - it takes an async iterable, or failing that, an iterable, or failing that, an arraylike.

[senocular]

There is no way to know from just holding an iterable whether it has eagerly created all its values or not, and the safe thing to do is assume it hasn't.

Wouldn't the safest thing to do be not try to assume either way?

We can either eagerly consume sync iterators (and array-likes) or not. If we do, we save ourselves from possible unhandled rejections with eagerly created rejecting promises. If not we allow sync iterators to be consumed asynchronously which allows for lazy creation dependent on the results of prior iterations... though if they're implemented as sync iterators, would they even expect to be dependent on that in the first place?

[ljharb]

Unhandled rejections aren't something that needs "saving" from. Promise.reject() is a normal part of the language and not some inherent danger.

If you don't want your rejections unhandled, you need to handle them. I don't see how Array.fromAsync needs to take that burden for you, that's not what it's for.

[senocular]

If you don't want your rejections unhandled, you need to handle them. I don't see how Array.fromAsync needs to take that burden for you, that's not what it's for.

I want to handle them but through the promise returned by Array.fromAsync as I would be able to for the burdens of:

// These create promises that will reject with err.
Array.fromAsync(badIterable);
Array.fromAsync(genError());
Array.fromAsync(genRejection());
Array.fromAsync(genErrorAsync());
Array.fromAsync([1], badCallback);
BadConstructor.call(Array.fromAsync, []);
// These create promises that will reject with TypeErrors.
Array.fromAsync(null);
Array.fromAsync([], 1);