-
Notifications
You must be signed in to change notification settings - Fork 5
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
keep-test: ETH faucet #174
Conversation
In order for the freshly minted keep-test-eth-faucet Heimdall script to run we need web3 commands available. Here we install that package.
We run a handful of internal ethereum chains, they're a pain in the ass to fund accounts on. You have to use the geth console, or geth CLI to transfer eth. Our keep-test environment has a public transaction node. This means we can take advantage of Heimdall to fund accounts on this chain, instead of having to use the aforementioned methods. Here we provide a very basic Heimdall command that funds a passed account with 10 eth.
Can go either way really...but we need to whole-ass whichever way that is.
I haven't dug into the code yet, but I do have one minor procedural note: we're using a pre-commit hook for linting with (This should probable be added to the project's README, sorry 😬 -- feel free to add it if you're inspired) |
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 hi, I know this is still in draft, so apologies if you weren't looking for notes yet (I wasn't sure if the 👀 were an invitation for notes or just a peek).
I'm still trying to wrap my head around what needs to be done to fix the log ordering issue discussed here.
In the meantime I wanted to add a small note or two.
scripts/keep-test-eth-faucet.js
Outdated
|
||
const web3 = new Web3(new Web3.providers.HttpProvider(ethHost + ':' + ethRpcPort), null, web3_options); | ||
|
||
module.exports = async function(robot) { |
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 don't think you want the async
here at the module.export
, only within the definitions of the functions for the commands themselves.
I may be wrong on this -- tbh I don't know if it will hurt anything -- but I don't see a precedent for it in our other scripts. (But please correct me if you had a reason for putting it 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.
I want to say I tried this and ran into an error regarding await
only being usable in async
functions. Will test again.
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.
^ was wrong, works fine w/out async
scripts/keep-test-eth-faucet.js
Outdated
msg.send(`Account ${purse} unlocked!`); | ||
} catch (error) { | ||
robot.logger.error(`ETH account unlock error: ${error.message}`); | ||
msg.send('There was an issue unlocking the purse account, ask for an adult!'); |
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.
ask for an adult
lolololololol
I wanted to follow up here with a couple notes I left in flowdock, so you'd have review-related conversations all in one place:
|
Rather than peg the script to an environment we're making the naming generic, with a note that the script only works for keep-test at the moment. This is to set the intention that we should be able to use this script for multiple environments, it just needs to be extended.
We were using mixed mode variable expansion in strings, I updated the one outlier to match the rest of the script. Also added a note that this script only works with keep-test at the moment.
Eventually we'll be able to pass an environment as an argument to this command. For now we shorten and make the faucet invocation command generic, as it should be.
Frankly I'm not sure why we can do this. In previous experience you had to use async/await all the way up the path, else you would run into runtime errors regarding using await in a non-async function.
It's a bit unnecessary from the perspective of the person being funded. They don't care where the ETH comes from, and we as operators know who the purse is.
In an effor to enforce ordering we wrap the msg.send calls for await results in then. This seems to work, however it produces a new scenario where then then log is returned before the msg.send message that should fire BEFORE the await. Need to look closer.
we need to exit on catch, adding a return so that if we catch we don't try to continue the script.
The "account" in this case is the purse. We should clarify that this password is for the purse, not just an eth account.
tl;dr here is that we think the ordering issues on Flowdock are due to the fact that the unlocked and funding msg.sends are firing at about the same time, and that Flowdock doesn't guarantee ordering in that case. We're just going to go ahead and remove the unlocked log, as this falls over if the accounnt isn't unlocked anyway (and we have logging for that).
Needed to update the usage comment after shortening the command. This also includes changes made by prettier.
Done. |
👀 |
We got 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.
This has been fun to watch evolve, excited to get it live so folks can use it!
@sthompson22 -- The addition of It's not a significant time hit on the install time (1.323s to 2.178s, on my laptop), but as the install logs scroll by, it's clear there's a LOT more going on now. Even though only (heh, only) 236 packages were added, that translates to a huge increase of the number of packages audited (from 1038 packages to 22883). The I haven't dug deep enough to know whether or not that's possible in this case. At first glance, it looks like maybe we could switch to importing Wanted to run the thought by you though and see what you think? |
(Following up here after chatting about the previous comment in a call with @sthompson22 ) Sloan will look into the above, to see if it is doable/ if it helps, but there's no urgency around it at all. Also, he noticed (and I missed in review) that his help text isn't consistent with our other commands. We discussed the existing conventions, and that the help should change from Sloan is planning an enhancement to this script, and will update when he works on that :) |
Intro
Sending ETH around is a pain in the ass. To try and help ease that burden a bit we want to make it so folks can fund ETH accounts via Heimdall.
Here we provide the first iteration of this with a command that will fund an ETH account that exists in the
keep-test
environment. We chosekeep-test
because it's active fortBTC
testing, this should make it easier for devs where they need it most.How it works
eth-faucet fund <target account>
fund
is the only command that exists at the moment.Testing
closes: #176