Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Core: ensure process-queue advances with rejected promises #1391
base: main
Are you sure you want to change the base?
Core: ensure process-queue advances with rejected promises #1391
Changes from all commits
091b03b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've extracted and applied this, with credit, via #1562 (released since then).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added tests for this scenario in #1634, and addressed the bug this fixes (#1446) via a different approach in #1638. In a nutshell, we handle this via the
unhandledrejection
event in the browser and Node.js, same as before, but previously that didn't work right due to it creating a fake test which we no longer do.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use of
setTimeout
must be conditional for non-browser environments such as SpiderMonkey (see other references). An alternate approach here can be to usePromise.resolve()
as fallback forsetTimeout
, or to avoid this alltogether by usingPromise.finally()
for the executeCallback, which naturally forwards the original rejection/error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that this particular thenable chain might be better without a local error handler as otherwise it means that the last error will be reported instead of the first one. I general QUnit's test logic is modelled to continue after assertion failures, but for uncaught exceptions I think we generally want to stop after the first for any given sequence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
advanceing
->advancing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
task()
throws a synchronous error, thecatch
bellow which would invokethrowAndAdvance
won't be invoked. I'm guessing this isn't intentional, and regardless if task throws synchronously or asynchronously, we would expect thecatchAndAdance
to be invoked.The following would rectify that issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to have
throwAndAdvance
both in the then's rejection handler, and in the subsequentcatch
?As implemented if the
throwAndAdvance
on line 79 is invoked, it will also cause thethrowAndAdvance
on line 80 to be invoked.I believe the intention here may be:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this will swallow any errors at this point - is that the desired behavior here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikrostew I assuming you are talking about
const callbackPromises = notStartedModules.reduce(...);
?if any of the promise from callbackPromises reject.. the whole promise should reject.. which should be handled on line 154:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was specifically looking at the line
If something in
promiseChain
resolves, then it calls the first function argumentmoduleStartCallback
, no problem. But it looks like if it rejects (because of some error) it will call the second function argument, which is alsomoduleStartCallback
, which doesn't do anything with the error that it receives. So that rejection will stop there, so thatcallbackPromises
won't reject.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read this again, this shouldn't be a problem, but I can understand why it looks like the error is swallowed.
For a bit more context..
const callbackPromises = notStartedModules.reduce(...);
ensures the callbacks from notStartedModules are promisfied sequentually, so each callback that was made into a promise, an awaited for until the next callback is executed and made into a promise.so You will get an chain of promises. In that chain, if there is one rejected promise, then the whole promise chain is rejected.
return promiseChain.then( moduleStartCallback, moduleStartCallback );
in this case, only ensures the next callback is promisfied even if the previous promise rejects. But as stated above, lien 154 will ensure the error is thrown.I hope that makes more sense.. I think I should likely find a better way to code the explanation above up