-
Notifications
You must be signed in to change notification settings - Fork 211
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
Track stake key registrations independently from delegation #1851
Conversation
(DelegationCertificate wid sl Nothing) | ||
pure <$> repsert | ||
(StakeKeyCertificateKey wid sl) | ||
(StakeKeyCertificate wid sl False) |
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.
Here we insert "deregistration" into both tables
This seems wrong. Stake key de-registration should be tracked separately as well, and the delegation status should be inferred from the database current status (as it is now). |
StakeKeyCertificate | ||
stakeKeyCertWalletId W.WalletId sql=wallet_id | ||
stakeKeyCertSlot W.SlotId sql=slot | ||
stakeKeyCertIsReg Bool sql=is_reg |
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'd recommend using something more explicit than a boolean here. Boolean convey very little information and they are easy to misinterpret (like I did on my first review...). I'd suggest something like Registration | Deregistration
, stored as plain text lowercased in the database, so it's also readable when debugging / inspecting.
[Desc StakeKeyCertSlot] | ||
|
||
return $ case val of | ||
Nothing -> Left $ ErrNoSuchWallet wid |
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.
Hmmm. No. There could be a wallet but no key. This should return negatively about the existing of a key, but not return an error. To know whether there's a wallet, this should use the same pattern as for other functions:
selectWallet wid >>= \case
Nothing -> pure $ Left $ ErrNoSuchWallet wid
Just{} -> {- ... do actual stuff ... -}
stakeKeyCertSlot W.SlotId sql=slot | ||
stakeKeyCertIsReg Bool sql=is_reg | ||
|
||
Primary stakeKeyCertWalletId stakeKeyCertSlot |
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.
👍
@@ -676,7 +676,8 @@ fromShelleyDelegationCert = \case | |||
SL.DCertDeleg (SL.DeRegKey credentials) -> | |||
Just $ W.CertDelegateNone (fromStakeCredential credentials) | |||
|
|||
SL.DCertDeleg SL.RegKey{} -> Nothing | |||
SL.DCertDeleg (SL.RegKey cred) -> | |||
Just $ W.CertRegisterKey $ fromStakeCredential cred |
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.
👍
[Desc StakeKeyCertSlot] | ||
return $ case val of | ||
Nothing -> Right False | ||
Just (StakeKeyCertificate _ _ isReg) -> Right isReg |
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.
👍
To delegate in shelley we need to know whether we need to register the stake key, or if it already exists. Trying to register the same key twice will cause the delegation to fail. In shelley there are three delegation certs: - reg - dereg - delegate We need to keep track of two things: - Delegation status - Is the stake key registered or not? (new in this commit) Also new in this commit: - Stake key de-registration inserts an uptdate to the delegation status table that says that it is not delegating.
Booleans are error-prone and convey very little information without surrounding context. A sum-type is cheap and much easier to read and debug (even in the database!). Co-authored-by: KtorZ <matthias.benkort@iohk.io>
1d3aa95
to
68fbe3b
Compare
68fbe3b
to
8a33b1e
Compare
to allow tests to call it
STAKE_POOLS_JOIN_05 This is a regression test for "Cannot join pool with ITN rewards wallet on shelley testnet"
"passphrase": "Secure Passphrase" | ||
} |] | ||
|
||
threadDelay 4000000 |
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.
Should use eventually
I guess
lib/shelley/test/integration/Main.hs
Outdated
|
||
-- | Pre-register a staking key for the STAKE_POOLS_JOIN_05 test. | ||
preregisterStakingKeysForTests :: NetworkLayer IO t b -> IO () | ||
preregisterStakingKeysForTests nl = do |
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 am not fond of having this function here but I guess it'll do for now. Ideally, I'd have put that where the rest of the "setup & fixture" work is happening (i.e. in the "Launch" module).
lib/shelley/test/integration/Main.hs
Outdated
, outputs = [] | ||
, change = [] | ||
, deposit = 100000 -- keyDeposit | ||
} |
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.
CoinSelection is a Monoid
, so you can write instead:
mempty { inputs = [(txIn, dummyOut)], deposit = 100000 }
Also, note that the key deposit is available in protocol parameters, would be better than hard-coding 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.
key deposit is available in protocol parameters
👍
CoinSelection is a Monoid
Didn't think about it, but in this case I found it useful to explicitly see the new fields of CoinSelection
.
data StakeKeyCertificate | ||
= StakeKeyRegistration | ||
| StakeKeyDeregistration | ||
deriving (Generic, Show, Read, Eq) |
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 are so many different kinds of certificate types in here already, for multiple purposes. I'd preferred to keep it closer to the DB.
"passphrase": "Secure Passphrase" | ||
} |] | ||
|
||
threadDelay 4000000 |
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 the delay?
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.
We try to join immediately when the wallet is created. It has no time to find the existing key reg cert.
Should probably use eventually
though. Just sprinkled it in to get it passing.
So that we don't get to look at so many places when trying to figure out how the test cluster is setup. It's also using the cardano-cli for consistency with other fixtures (and because we have nice logging and retrying in place for this in the module already).
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.
Reviewed, partially fixed and partially extended.
bors r+ |
1851: Track stake key registrations independently from delegation r=KtorZ a=Anviking # Issue Number #1835 # Overview - [x] Keep track of stake key registrations such that we don't try to register a key twice - [ ] TODO: model impl - There was a integration test, which I saw passing at some point, but I've not rebased it to this PR - Some DB model-like tests would have been nice, but no time now # Comments To delegate in shelley we need to know whether we need to register the stake key, or if it already exists. Trying to register the same key twice will cause the delegation to fail. In shelley there are three delegation certs: - reg - dereg - delegate We need to keep track of two things: - Delegation status - Is the stake key registered or not? (new in this commit) Also new in this commit: - Stake key de-registration inserts an uptdate to the delegation status table that says that it is not delegating. <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <johannes.lund@iohk.io> Co-authored-by: KtorZ <matthias.benkort@gmail.com>
Canceled |
bors r+ |
1851: Track stake key registrations independently from delegation r=KtorZ a=Anviking # Issue Number #1835 # Overview - [x] Keep track of stake key registrations such that we don't try to register a key twice - [ ] TODO: model impl - There was a integration test, which I saw passing at some point, but I've not rebased it to this PR - Some DB model-like tests would have been nice, but no time now # Comments To delegate in shelley we need to know whether we need to register the stake key, or if it already exists. Trying to register the same key twice will cause the delegation to fail. In shelley there are three delegation certs: - reg - dereg - delegate We need to keep track of two things: - Delegation status - Is the stake key registered or not? (new in this commit) Also new in this commit: - Stake key de-registration inserts an uptdate to the delegation status table that says that it is not delegating. <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <johannes.lund@iohk.io> Co-authored-by: KtorZ <matthias.benkort@gmail.com>
These tests are quite flaky and often failing for no reason. Plus, they are testing things at the integration level since they require a running node and they are redundant with other integration scenario that are ran as part of the integration test suite
734604d
to
fc77374
Compare
Canceled |
bors r+ |
1851: Track stake key registrations independently from delegation r=KtorZ a=Anviking # Issue Number #1835 # Overview - [x] Keep track of stake key registrations such that we don't try to register a key twice - [ ] TODO: model impl - There was a integration test, which I saw passing at some point, but I've not rebased it to this PR - Some DB model-like tests would have been nice, but no time now # Comments To delegate in shelley we need to know whether we need to register the stake key, or if it already exists. Trying to register the same key twice will cause the delegation to fail. In shelley there are three delegation certs: - reg - dereg - delegate We need to keep track of two things: - Delegation status - Is the stake key registered or not? (new in this commit) Also new in this commit: - Stake key de-registration inserts an uptdate to the delegation status table that says that it is not delegating. <!-- Don't forget to: ✓ Self-review your changes to make sure nothing unexpected slipped through ✓ Assign yourself to the PR ✓ Assign one or several reviewer(s) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: Johannes Lund <johannes.lund@iohk.io> Co-authored-by: KtorZ <matthias.benkort@gmail.com>
Canceled |
bors r+ |
Build succeeded |
Issue Number
#1835
Overview
Comments
To delegate in shelley we need to know whether we need to register the
stake key, or if it already exists. Trying to register the same key
twice will cause the delegation to fail.
In shelley there are three delegation certs:
We need to keep track of two things:
Also new in this commit:
table that says that it is not delegating.