-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Run each console command in its own child process #3255
Conversation
try { | ||
this.provision(); | ||
} catch (e) { | ||
console.log(e); | ||
} | ||
} catch (err) { | ||
callback(err); | ||
} |
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 the intention to eat exceptions thrown by this.provision()
and not invoke the callback on 160?
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.
Unless I'm misunderstanding, the callback on lime 160 is for any exceptions thrown by spawning the repl. There's a try/catch for this.provision()
and a try/catch for the spawning. Does that make sense or am I not following?
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 intention is a bit hard to follow because the two catch expressions are next to each other. As it exists, if the provision after spawn fails then the code explicitly eats the error and continues execution to the next REPL prompt. Is an exception thrown by this.provision()
benign as the code suggests?
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.
this.provision();
can throw an Error (line 110) if something is awry with an artifact file. I think we should be invoke the callback in the outer catch block.
Hey @fainashalts, check out the bundled version of Truffle - there's a deprecation notice upon every child process:
(On Node v10.22) |
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.
Few more comments for you @fainashalts.
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.
Marking this as "request changes" until we can resolve that Buffer() error (or at least get to the bottom of it!)
packages/core/lib/console-child.js
Outdated
const Web3 = require("web3"); | ||
|
||
const inputStrings = process.argv[2]; | ||
const network = process.argv[3]; |
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.
Can we merge these two? i.e., if the user runs debug --network mainnet
from inside truffle console --network development
, then I would expect the debug
command to connect to mainnet. This implementation suggests that behavior might be undefined (or favor the network specified by process.argv[3]
)
Seems like we shouldn't pass network
separately as a positional argument, and instead pass it as a named --network
option. Two options come to mind for how to do that:
-
Add logic to the parent process to merge
--network=<network-name>
intoinputStrings
, possibly by decodinginputStrings
into a mapping + then re-encoding with{ network }
merged in. -
Use a
--
separator between parent-process-provided options and user-provided options, e.g.:
truffle(develop)> debug <tx-hash> --fetch-external
... would run command:
$ console-child.js --network=develop -- debug <tx-hash> --fetch-external
from parent ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ from user
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.
Hi @gnidan so I don't think it's necessary to make this change - as far as I can tell, passing debug --network mainnet
does run debug on mainnet even if truffle console
was passed a different network. I tested with truffle console --network development
and then debug <txhash> --network test
, which I had running on a different port. The behavior is as expected. Let me know if that's not sufficient or if I'm missing something.
I'm actually not passing network to the run process, just in order to do a Config.detect()
in order to get the develop
network set up for the ganache url we pass to set up the provider (I know it's a separate consideration re: the hardcoded develop logic, which we've decided to address separately I believe).
If this is more of a concern re: having network as a positional argument from the parent, I can do a merge but it sort of seems unnecessary to me? Let me know what you think, thanks!
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.
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 so much @fainashalts, thanks for knocking that out!
That PR looks great! But why is it failing
- Move runSpawn function to console.js file - Write console-child.js to handle child behavior - Serialize and deserialize config options where possible - Detect config again from child to avoid serialization issues for provider and resolver
c2b5cf3
to
79ae210
Compare
Pass network as a named --network option instead of positionally
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 this is good to go!
@eggplantzzz I think when you do the release this week, you should enlist a bunch of us to participate in smoke-testing to give this the extra diligence it needs.
This PR runs commands from inside the
truffle develop
andtruffle console
command processes. While this PR changes the waytruffle develop
andtruffle console
work under the hood, the end user CLI experience should not be different.These changes became necessary when we found that Node v12 does not allow
UncaughtException
listeners in a REPL within another NodeJS program, and that one of our dependencies uses such a listener. By running a separate REPL in a child process we are able to bypass this problem. The issue that brought this to our attention is here: #2463In the process of this work, it became apparent that the ReplManager class we had been using to manage multiple REPLs was no longer necessary since each REPL will now be in its own process. This PR thus also removes the
repl.js
file and directly accesses the node REPL as needed inconsole.js
andinterpreter.js
.To test this PR, run either
truffle develop
ortruffle console
and then use these to test out any other Truffle commands that make sense:migrate --reset
,compile
,test
,debug
, etc. Everything should work as it did previously, with the exception that the--network
flag will throw an error when used withtruffle develop
-- the only network that should be used bytruffle develop
is thedevelop
network.