test: port domains regression test from v0.10 #3356
Conversation
misterdjules
added
domain
|
/cc @nodejs/collaborators |
|
CI: https://ci.nodejs.org/job/node-test-commit/832/ lint issue: |
| @@ -0,0 +1,32 @@ | |||
| 'use strict'; | |||
|
|
|||
misterdjules
force-pushed
the
port-domains-clears-stack-test
branch
from
37e358e
to
8a0518e
Compare
|
@jbergstroem @thefourtheye Thanks for catching the lint issue, and my apologies for not running |
misterdjules
force-pushed
the
port-domains-clears-stack-test
branch
from
8a0518e
to
6feb953
Compare
|
Heading into cosmetics here, but could we perhaps use the shortform git commit sha's instead? Github automatically formats to this which makes the commit message look a bit weird unless read through -HTML. |
| // handled the original error, thus throwing here would trigger another | ||
| // call to process._fatalException, and so on recursively and | ||
| // indefinitely. | ||
| process.exit(1); |
There was a problem hiding this comment.
Maybe use process.abort() instead?
There was a problem hiding this comment.
What is the advantage of using process.abort over process.exit in this case? One disadvantage I can think of is that it could create core files on some systems depending on their configuration.
There was a problem hiding this comment.
Yes, that's a disadvantage. The advantage is that it's a lot more noisy than process.exit(1) is.
There was a problem hiding this comment.
It will make this test take quite a bit longer on OS X at least too
There was a problem hiding this comment.
Agreed. What about adding a noisy console.error output?
There was a problem hiding this comment.
Updated this PR and added a console.error output before exiting, let me know what you think.
|
LGTM with two suggestions. |
|
@jbergstroem @bnoordhuis Thanks for the review, will update shortly. @jbergstroem Regarding using full commits shas: I always use full shas when I want to make sure that they can be found a long time after the commit message was written. It's difficult to determine how long git commit shas should be to never be ambiguous throughout the lifetime of the project. So instead of relying on guessing, I always include the full sha and I'm confident that anyone will be able to use them and unambiguously retrieve their corresponding changes. |
misterdjules
force-pushed
the
port-domains-clears-stack-test
branch
from
6feb953
to
b2d7301
Compare
|
@jbergstroem @bnoordhuis Updated, please take a look. |
| 'use strict'; | ||
|
|
||
| const domain = require('domain'); | ||
| const common = require('../common'); |
There was a problem hiding this comment.
common should be the first import.
There was a problem hiding this comment.
Right, updated, thank you.
f2a45ca contained a test for a regression that had been introduced by the original change that 77a10ed ported. While 77a10ed did not contain that regression, the test that f2a45ca contained should still be in the code base to prevent any regression from happening in the future. Original message for the commit that contained the test: domains: fix stack clearing after error handled caeb677 introduced a regression where the domains stack would not be cleared after an error had been handled by the top-level domain. This change clears the domains stack regardless of the position of the active domain in the stack. PR: nodejs#9364 PR-URL: nodejs/node-v0.x-archive#9364 Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]>
misterdjules
force-pushed
the
port-domains-clears-stack-test
branch
from
b2d7301
to
8b58dfa
Compare
|
@jbergstroem @bnoordhuis ping. Let me know if my latest comments and updates address your concerns. |
f2a45ca contained a test for a regression that had been introduced by the original change that 77a10ed ported. While 77a10ed did not contain that regression, the test that f2a45ca contained should still be in the code base to prevent any regression from happening in the future. Original message for the commit that contained the test: domains: fix stack clearing after error handled caeb677 introduced a regression where the domains stack would not be cleared after an error had been handled by the top-level domain. This change clears the domains stack regardless of the position of the active domain in the stack. PR: #9364 PR-URL: nodejs/node-v0.x-archive#9364 Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> PR: #3356 PR-URL: #3356 Reviewed-By: Ben Noordhuis <[email protected]>
|
Thank you, landed in 642928b. |
|
@jasnell will tests like this make their ways into LTS? |
|
@thealphanerd That's a good question. My opinion is that yes, they should because they can only help make LTS releases more solid. Hence tagging this PR with land-on-v4.x. |
f2a45ca contained a test for a regression that had been introduced by the original change that 77a10ed ported. While 77a10ed did not contain that regression, the test that f2a45ca contained should still be in the code base to prevent any regression from happening in the future. Original message for the commit that contained the test: domains: fix stack clearing after error handled caeb677 introduced a regression where the domains stack would not be cleared after an error had been handled by the top-level domain. This change clears the domains stack regardless of the position of the active domain in the stack. PR: #9364 PR-URL: nodejs/node-v0.x-archive#9364 Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> PR: #3356 PR-URL: #3356 Reviewed-By: Ben Noordhuis <[email protected]>
f2a45ca contained a test for a regression that had been introduced by the original change that 77a10ed ported. While 77a10ed did not contain that regression, the test that f2a45ca contained should still be in the code base to prevent any regression from happening in the future. Original message for the commit that contained the test: domains: fix stack clearing after error handled caeb677 introduced a regression where the domains stack would not be cleared after an error had been handled by the top-level domain. This change clears the domains stack regardless of the position of the active domain in the stack. PR: #9364 PR-URL: nodejs/node-v0.x-archive#9364 Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> PR: #3356 PR-URL: #3356 Reviewed-By: Ben Noordhuis <[email protected]>
|
Landed in v4.x-staging in b8869bd |
f2a45ca contained a test for a regression that had been introduced by the original change that 77a10ed ported. While 77a10ed did not contain that regression, the test that f2a45ca contained should still be in the code base to prevent any regression from happening in the future. Original message for the commit that contained the test: domains: fix stack clearing after error handled caeb677 introduced a regression where the domains stack would not be cleared after an error had been handled by the top-level domain. This change clears the domains stack regardless of the position of the active domain in the stack. PR: #9364 PR-URL: nodejs/node-v0.x-archive#9364 Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Julien Gilli <[email protected]> PR: #3356 PR-URL: #3356 Reviewed-By: Ben Noordhuis <[email protected]>
f2a45ca contained a test for a
regression that had been introduced by the original change that
77a10ed ported. While
77a10ed did not contain that
regression, the test that f2a45ca
contained should still be in the code base to prevent any regression
from happening in the future.
Original message for the commit that contained the test:
domains: fix stack clearing after error handled
caeb677 introduced a regression where
the domains stack would not be cleared after an error had been handled
by the top-level domain.
This change clears the domains stack regardless of the position of the
active domain in the stack.
PR: #9364
PR-URL: nodejs/node-v0.x-archive#9364
Reviewed-By: Trevor Norris [email protected]
Reviewed-By: Julien Gilli [email protected]