-
Notifications
You must be signed in to change notification settings - Fork 214
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
Rewards detection in multisig #3872
Conversation
cd9682c
to
8385923
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.
LGTM, but just realised concern with roundtrip of RewardAccount
, and there are some fromJust
which shouldn't be needed
data RewardAccountSource | ||
= RewardAccountFromKeyHash | ||
| RewardAccountFromScriptHash | ||
deriving (Eq, Show) | ||
|
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.
Shouldn't be needed any longer
data RewardAccountSource | |
= RewardAccountFromKeyHash | |
| RewardAccountFromScriptHash | |
deriving (Eq, Show) |
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.
indeed
show (CmdAdversarialReg (FromKeyHash a)) = "CmdAdversarialReg " <> B8.unpack a | ||
show (CmdAdversarialReg (FromScriptHash a)) = "CmdAdversarialReg " <> B8.unpack a |
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.
These changes look inconvenient, but still preferable to having two reward observers I think.
, "detection. Either there is db malfunction or managing rewards " | ||
, "was used for shared wallets missing delegation template." |
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'm guessing this error should never hit users of the API (if manageSharedRewardBalance
is only called for wallets with delegation templates). Should it be err500
instead then?
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.
indeed, err500 is better here
verify r | ||
[ expectField | ||
(#balance . #reward) | ||
(.> (Quantity 0)) |
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.
👌 nice!
lib/wallet/src/Cardano/Wallet.hs
Outdated
manageSharedRewardBalance | ||
:: forall n block | ||
. Tracer IO WalletWorkerLog | ||
-> NetworkLayer IO block | ||
-> DBLayer IO (SharedState n SharedKey) SharedKey | ||
-> WalletId | ||
-> IO () | ||
manageSharedRewardBalance tr' netLayer db@DBLayer{..} wid = 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.
Could parts common to both manageSharedRewardBalance
and manageRewardBalance
be factored out?
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.
done
lib/wallet/src/Cardano/Wallet.hs
Outdated
when (isNothing acctM) $ | ||
throwE ErrFetchRewardsMissingRewardAccount | ||
liftIO $ getCachedRewardAccountBalance netLayer (fst $ fromJust acctM) |
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.
No need for fromJust
:
when (isNothing acctM) $ | |
throwE ErrFetchRewardsMissingRewardAccount | |
liftIO $ getCachedRewardAccountBalance netLayer (fst $ fromJust acctM) | |
case acctM of | |
Nothing -> throwE ErrFetchRewardsMissingRewardAccount | |
Just acct -> liftIO $ getCachedRewardAccountBalance netLayer (fst acct) |
liftHandler $ throwE ErrConstructTxDelegationInvalid | ||
let path = snd $ fromJust res |
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.
Same as other comment — fromJust
shouldn't be needed.
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.
done
delCerts <- case optionalDelegationAction of | ||
Nothing -> pure Nothing | ||
Just action -> do | ||
res <- liftHandler $ W.readSharedRewardAccount @n db 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.
At this point in the flow, we've already managed to create a balanced transaction, so I believe the ErrConstructTxDelegationInvalid
would never been thrown from here. (not sure if there's an easy fix though)
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.
you are right. ErrConstructTxDelegationInvalid
will never be thrown here. If ever, it would be caught earlier. removed that.
properties: | ||
message: | ||
type: string | ||
description: May occur when there is a missing reward account but wallet participates in staking. |
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.
Same as in the other comment, users would run into ErrDelegationInvalid
but never this, modulo DB malfunctions?
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.
yes, MissingRewardAccount
is now err500 and can occur when there is no reward account in db (for example db malfunction), and DelegationInvalid
is user error (err403) occurring when user instantiate shared wallet with only spending script and creates tx with delegation action.
|
||
instance FromText RewardAccount where | ||
fromText = fmap (RewardAccount . getHash @"RewardAccount") . fromText | ||
fromText = fmap (FromKeyHash . getHash @"RewardAccount") . fromText |
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 wouldn't roundtrip... Could this be problematic for the DB?
If this is indeed a problem, maybe there's a middle ground between having RewardAccount = FromKeyHash ByteString | FromScriptHash ByteString
everywhere and having two newRewardBalanceFetcher
— e.g. having the same RewardAccount
as before but letting newRewardBalanceFetcher
operate on Either RewardAccount RewardAccount
(or something isomorphic) as opposed to having two of them?
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.
after some thought and having in mind db migrations I come up with the following solution:
instance ToText RewardAccount where
toText (FromKeyHash bs) = T.cons 'k' . toText . Hash @"RewardAccount" $ bs
toText (FromScriptHash bs) = T.cons 's' . toText . Hash @"RewardAccount" $ bs
instance FromText RewardAccount where
fromText txt = case T.splitAt 1 txt of
("s", txt') ->
fmap (FromScriptHash . getHash @"RewardAccount") . fromText $ txt'
("k", txt') ->
fmap (FromKeyHash . getHash @"RewardAccount") . fromText $ txt'
_ -> -- for backward compatibility when there is already db
fmap (FromKeyHash . getHash @"RewardAccount") . fromText $ txt
hash is represented as hex so 0-9af
alphabet. for key we prepend k
for script s
so outside the alphabet. Also to be backward compatible we fromText
to key version (as this is one we should care atm). core unit tests passes. Old data type with all consequences stays. I think we should be good.
c2cc8f6
to
59e1d32
Compare
_ -> -- for backward compatibility when there is already db | ||
fmap (FromKeyHash . getHash @"RewardAccount") . fromText $ txt |
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.
Ah 👍
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.
Btw: is there a roundtrip test for this instance? One that would have caught the previous failure to roundtrip?
59e1d32
to
294e8c8
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.
lgtm
_ -> -- for backward compatibility when there is already db | ||
fmap (FromKeyHash . getHash @"RewardAccount") . fromText $ txt |
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.
Btw: is there a roundtrip test for this instance? One that would have caught the previous failure to roundtrip?
294e8c8
to
10a5d8b
Compare
yes, there is roundtrip for "ApiRewardAccount" which is newtype wrapper for "RewardAccount". Still, I extended |
bors r+ |
3872: Rewards detection in multisig r=paweljakubas a=paweljakubas <!-- Detail in a few bullet points the work accomplished in this PR. Before you submit, don't forget to: * Make sure the GitHub PR fields are correct: ✓ Set a good Title for your PR. ✓ Assign yourself to the PR. ✓ Assign one or more reviewer(s). ✓ Link to a Jira issue, and/or other GitHub issues or PRs. ✓ In the PR description delete any empty sections and all text commented in <!--, so that this text does not appear in merge commit messages. * Don't waste reviewers' time: ✓ If it's a draft, select the Create Draft PR option. ✓ Self-review your changes to make sure nothing unexpected slipped through. * Try to make your intent clear: ✓ Write a good Description that explains what this PR is meant to do. ✓ Jira will detect and link to this PR once created, but you can also link this PR in the description of the corresponding Jira ticket. ✓ Highlight what Testing you have done. ✓ Acknowledge any changes required to the Documentation. --> - [x] Extending shared state - [x] add readRewardAccount - [x] add manageSharedBalance - [x] use manageSharedBalance - [x] impl IsOurs for RewardAccount - [x] extending integration testing (joining/rejoining) - [x] redefine RewardAccount and deal with code changes throughout all codebase ### Comments <!-- Additional comments, links, or screenshots to attach, if any. --> ### Issue Number adp-2603 <!-- Reference the Jira/GitHub issue that this PR relates to, and which requirements it tackles. Note: Jira issues of the form ADP- will be auto-linked. --> Co-authored-by: Pawel Jakubas <pawel.jakubas@iohk.io>
Build failed: |
@paweljakubas I see some integration tests fail with error 500 from the API:
I observe the same when trying to create "incomplete" shared wallet on
👇
In the log there is:
|
10a5d8b
to
10fb99a
Compare
bors r+ |
3872: Rewards detection in multisig r=paweljakubas a=paweljakubas <!-- Detail in a few bullet points the work accomplished in this PR. Before you submit, don't forget to: * Make sure the GitHub PR fields are correct: ✓ Set a good Title for your PR. ✓ Assign yourself to the PR. ✓ Assign one or more reviewer(s). ✓ Link to a Jira issue, and/or other GitHub issues or PRs. ✓ In the PR description delete any empty sections and all text commented in <!--, so that this text does not appear in merge commit messages. * Don't waste reviewers' time: ✓ If it's a draft, select the Create Draft PR option. ✓ Self-review your changes to make sure nothing unexpected slipped through. * Try to make your intent clear: ✓ Write a good Description that explains what this PR is meant to do. ✓ Jira will detect and link to this PR once created, but you can also link this PR in the description of the corresponding Jira ticket. ✓ Highlight what Testing you have done. ✓ Acknowledge any changes required to the Documentation. --> - [x] Extending shared state - [x] add readRewardAccount - [x] add manageSharedBalance - [x] use manageSharedBalance - [x] impl IsOurs for RewardAccount - [x] extending integration testing (joining/rejoining) - [x] redefine RewardAccount and deal with code changes throughout all codebase ### Comments <!-- Additional comments, links, or screenshots to attach, if any. --> ### Issue Number adp-2603 <!-- Reference the Jira/GitHub issue that this PR relates to, and which requirements it tackles. Note: Jira issues of the form ADP- will be auto-linked. --> Co-authored-by: Pawel Jakubas <pawel.jakubas@iohk.io>
Build failed: |
clean
10fb99a
to
352dda7
Compare
bors r+ |
Build succeeded: |
…a=paweljakubas <!-- Detail in a few bullet points the work accomplished in this PR. Before you submit, don't forget to: CODE-OF-CONDUCT.md LICENSE README.md bors.toml cabal.project default.nix docker-compose.yml docs flake.lock flake.nix floskell.json hie-direnv.yaml lib nix prototypes reports scripts shell.nix specifications test touch.me.CI weeder.dhall Make sure the GitHub PR fields are correct: ✓ Set a good Title for your PR. ✓ Assign yourself to the PR. ✓ Assign one or more reviewer(s). ✓ Link to a Jira issue, and/or other GitHub issues or PRs. ✓ In the PR description delete any empty sections and all text commented in <!--, so that this text does not appear in merge commit messages. CODE-OF-CONDUCT.md LICENSE README.md bors.toml cabal.project default.nix docker-compose.yml docs flake.lock flake.nix floskell.json hie-direnv.yaml lib nix prototypes reports scripts shell.nix specifications test touch.me.CI weeder.dhall Don't waste reviewers' time: ✓ If it's a draft, select the Create Draft PR option. ✓ Self-review your changes to make sure nothing unexpected slipped through. CODE-OF-CONDUCT.md LICENSE README.md bors.toml cabal.project default.nix docker-compose.yml docs flake.lock flake.nix floskell.json hie-direnv.yaml lib nix prototypes reports scripts shell.nix specifications test touch.me.CI weeder.dhall Try to make your intent clear: ✓ Write a good Description that explains what this PR is meant to do. ✓ Jira will detect and link to this PR once created, but you can also link this PR in the description of the corresponding Jira ticket. ✓ Highlight what Testing you have done. ✓ Acknowledge any changes required to the Documentation. --> - [x] Extending shared state - [x] add readRewardAccount - [x] add manageSharedBalance - [x] use manageSharedBalance - [x] impl IsOurs for RewardAccount - [x] extending integration testing (joining/rejoining) - [x] redefine RewardAccount and deal with code changes throughout all codebase ### Comments <!-- Additional comments, links, or screenshots to attach, if any. --> ### Issue Number adp-2603 <!-- Reference the Jira/GitHub issue that this PR relates to, and which requirements it tackles. Note: Jira issues of the form ADP- will be auto-linked. --> Co-authored-by: Pawel Jakubas <pawel.jakubas@iohk.io> Source commit: 56b346a
Comments
Issue Number
adp-2603