-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
repl: catch promise errors during eval in completion #58943
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #58943 +/- ##
==========================================
- Coverage 90.07% 90.04% -0.04%
==========================================
Files 641 641
Lines 188998 189007 +9
Branches 37069 37079 +10
==========================================
- Hits 170246 170192 -54
- Misses 11462 11515 +53
- Partials 7290 7300 +10
🚀 New features to boost your workflow:
|
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.
The fix itself looks good to me, however I feel like the tests could be improved
{ send: `async function f() {}; f().` }, | ||
]; | ||
|
||
const tests = [ |
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.
Why are there non-completion tests here?
If these tests are necessary I would suggest to have them in their own separate test file, I don't think there's any benefit in running both set of tests here, is there?
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 had originally added it just to be safe, even though I knew it wouldn't have any real effect.
But since it’s not strictly necessary, I’ve removed it.
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 think we can add it as a separate test file, as I had a quick look and I feel like promise evaluation is not being tested? anyways that can be also done separately if we want I think 🙂
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.
Oh I see, I'll keep it as well in a separate file.
Is it okay to include that in this PR?
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.
Oh I see, I'll keep it as well in a separate file.
yeah sounds good to me 🙂
Is it okay to include that in this PR?
Of course 🙂
If you're up for it I think it would be great if you could rebase and have two commits here, one for the tab-complete and one for the new eval tests then we can commit-queue-rebase
and have the two clean commits in, I think that that would be the cleanest way to land this 🙂 , but if you don't feel like it the current merge squash is completely fine too 👍
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 rebased the branch!
await runReplTests(tests); | ||
})().then(common.mustCall()); | ||
|
||
async function runReplCompleteTests(tests) { |
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.
In my opinion tab completion tests should use the repl's complete
function as I think that it is the cleanest most robust/stable way for testing this functionality (no need to collect the repl output and add setTimeout
s).
For example you can see here: https://github.com/dario-piotrowicz/node/blob/34f24960fb813609f3bd0080ac26bbee1611f142/test/parallel/test-repl-tab-complete-computed-props.js how I recently did it
You can also notice in my tests that the strategy allows to use a single repl instance (since anyways the tests don't rely on state) instead of creating a new one every time
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.
Thanks, Your approach definitely makes things much simpler.
I've updated the tests to use repl.complete, and also renamed the file accordingly to reflect the change.
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 great, thanks for the updates @islandryu 🫶
@dario-piotrowicz |
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.
@dario-piotrowicz Could you take another look? I’ve updated the commit. I only resolved conflicts with the main branch.
Hi @islandryu 👋
Sorry about the merge conflicts those were my fault 🙇
The changes still look good to me 😄
However now there's an extra eval that I think should also include your check:
Line 1822 in 7b2d30c
`try { ${exprStr} } catch {} `, ctx, getREPLResourceName(), (err, obj) => { |
If you could also add the check there (alongside a test if it's not too problematic) that'd be great 😄
But if you want I can also do that in a separate PR, up to you 🙂
Thanks for pointing that out! |
#59044 |
Fixes: #58903
The issue occurred when an unhandled Promise was executed during the completion's
eval
.This change catches and ignores the error, similar to the handling here.
node/lib/repl.js
Line 1544 in 6a3b545