-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spec Issue: IteratorStep returns a promise for async iterators, leading to an infinite loop #33
Comments
Good catch. The fix is a little more complicated than your suggestion, though. IteratorStep isn't usable at all with async iterators; it performs IteratorComplete on the result of the next method, which assumes the return value of that method is an iterator result, not a promise for one. I think instead we want to invoke the next method directly, like for await does (which is currently one of the only consumers of the async iteration protocol):
Alternatively, I suppose we could have |
Note: I'm preparing to ship Array.fromAsync. It will ship using the above spec-patch semantics. |
Fixes #33. Prevents an infinite loop caused by IteratorStep(iteratorRecord) not actually flagging termination when IteratorRecord is async. Instead, we will directly call iteratorStep.[[NextMethod]], like how `for await` does. Co-Authored-By: Kevin Gibbons <[email protected]>
Fixes #33. Prevents an infinite loop caused by IteratorStep(iteratorRecord) not actually flagging termination when IteratorRecord is async. Instead, we will directly call iteratorStep.[[NextMethod]], like how `for await` does. Co-Authored-By: Kevin Gibbons <[email protected]>
Fixes #33. Prevents an infinite loop caused by IteratorStep(iteratorRecord) not actually flagging termination when IteratorRecord is async. Instead, we will directly call iteratorStep.[[NextMethod]], like how `for await` does. Co-authored-by: Kevin Gibbons <[email protected]>
Finish #44’s change, which fixes #33. Co-Authored-By: Kevin Gibbons <[email protected]> #44 renamed _next_ to _nextResult_ but one reference was left unchanged. Spotted by @trflynn89.
Finish #44’s change, which fixes #33. Co-Authored-By: Kevin Gibbons <[email protected]> #44 renamed _next_ to _nextResult_ but one reference was left unchanged. Spotted by @trflynn89.
Finish #44’s change, which fixes #33. Co-Authored-By: Kevin Gibbons <[email protected]> #44 renamed _next_ to _nextResult_ but one reference was left unchanged. Spotted by @trflynn89.
In the published spec, Step 3.j.ii.3 and 4 are the termination condition of the iteration:
The problem is that
IteratorStep
doesn't properly flag termination on an async iterator; the return value of theIteratorNext
in async iteration is a Promise, which doesn't have a "done" property, and so we always get the promise object fromIteratorStep
.I think the patch is actually relatively simple; Step 3.j.ii.4 should be expanded into the steps which have the effect of "if
next.done
is false:"The text was updated successfully, but these errors were encountered: