-
Notifications
You must be signed in to change notification settings - Fork 43
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
feat(rpc): add flag for connext to unlock response #1967
Conversation
lib/cli/commands/unlock.ts
Outdated
} | ||
if (response.lockedLndsList.length) { | ||
console.log(`The following wallets could not be unlocked: ${response.lockedLndsList.join(', ')}`); | ||
console.log(`The following wallets could not be unlocked: ${readyClients.join(', ')}`); |
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.
it is incorrect handling of could not be unlocked
case.
- This case means that something wrong with L2 client and it can not be unlocked (
response.lockedLndsList
was used because of that before). - But for now it looks like
could not be unlocked
=client already unlocked
as a result it leads to incorrect erroe handling (my lnd can not be unlocked because something wrong with my docker network):
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 for catching this, it was an oversight on my part. If a client was already unlocked before the call, it should show up under the list of The following wallets are unlocked and ready
- along with the clients that were unlocked when we made this call. Only if the client could not be unlocked (due to being offline, wrong password, etc...) should it show up as could not be unlocked
.
40ffaba
to
444cb67
Compare
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 is very strange, I put in tests to double check the logic and everything seems fine. Can you try testing this one more time, and then right after connection can you do a getinfo call and ensure that Connext is running and connected? Thanks. |
checked again, same result, maybe the problem is in timing:
|
Thanks a lot for the thorough checks as usual, I'll get to the bottom of this tho it's still not clear what the issue is (almost certainly something small). |
b9b1f9c
to
ac18c97
Compare
Could you give this another try? Thanks for the hint about connext not initializing in time, I'm pretty sure that's what the issue was. |
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.
It looks like in all of those examples you pasted, BTC and LTC are always unlocked right? I don't have this printing I suppose I could add ETH to the list of "locked" clients (and probably rename it to "locked or not ready") but currently that would be set any time connext is disabled. So I might need to change the connext ready field from a true/false flag to an enum that's ready/not ready/disabled (and simply not print anything in the cli when its disabled). What do you think @kilrau? I'll rebase this PR again to resolve a conflict. |
This adds a flag to the `UnlockNode` response to indicate whether a Connext client is connected and ready to accept calls. In the cli, `ETH` gets added to the list of wallets that are unlocked and ready when this new flag is true. Closes #1932.
ac18c97
to
43e7e2f
Compare
For |
OK, if that's what we want then what we really need is a flag for when connext is not ready, and it's only true when both connext is enabled AND connext is not connected. Does that sound right? |
Yep! |
Can we continue with this one? @sangaman |
This adds a flag to the
UnlockNode
response to indicate whether a Connext client is connected and ready to accept calls. In the cli,ETH
gets added to the list of wallets that are unlocked and ready when this new flag is true.Closes #1932.