-
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
Refactor in preparation to reuse balanceTransaction
within quitStakePool
.
#3555
Conversation
33eecf8
to
c5c3b38
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.
Hi @Unisay
Thanks for making this PR!
From looking through, it seems that this PR makes a few distinct changes:
- Introduces various readability improvements. (Thanks for this! 💯 )
- Introduces the
WalletException
sum type, which groups together all the individual error types and replaces the use of "errors" with exceptions. - Restructures
mkRewardAccountBuilder
. - Reworks
quitStakePool
Can I trouble you with a very small request: would it be possible to separate this out into separate, smaller PRs? 🙏🏻
- Just the readability improvements on their own. (We could approve this very quickly.)
- Just the
WalletException
refactoring on its own. (This deserves more attention and discussion, I feel.) - Just the restructuring of
mkRewardAccountBuilder
. - The rework of
quitStakePool
.
In the current PR, the above changes are sometimes mixed together a bit. In particular, the WalletException
refactoring is bundled up together with a rework of quitStakePool
(in the final commit). But the WalletException
work is interesting in its own right (and deserving of its own review, IMO).
Many thanks! Let me know if I can help in any way.
c5c3b38
to
4bfe080
Compare
I am afraid that I see the overhead and effort associated with splitting this into individual PRs more vividly than benefits of doing it: Side note: in practice, such opportunistic-refactoring style modifications happen naturally and aren't well isolated, for example: I started reading code of the Anyway, I did my best grouping changes into individual commits (retrospectively), this should facilitate code review. |
d3af78c
to
a51009d
Compare
19f689c
to
03bfe2c
Compare
bors try |
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! Lgtm.
But it looks like bors try
is about to fail
Migration from Random wallet to target address count: 1. [✘] (1358ms)
Migration from Random wallet to target address count: 3. [✘] (3828ms)
Migration from Random wallet to target address count: 10. [✘] (4016ms)
Migration from Icarus wallet to target address count: 1. [✘] (4177ms)
Migration from Icarus wallet to target address count: 3. [✘] (4237ms)
Migration from Icarus wallet to target address count: 10. [✘] (1748ms)
tryBuild failed: |
d677889
to
e552b8c
Compare
shelleyOnlyRewardAccountBuilder | ||
:: forall s k (n :: NetworkDiscriminant) | ||
. ( HardDerivation k | ||
, Bounded (Index (AddressIndexDerivationType k) (AddressCredential k)) | ||
, WalletKey k | ||
, Typeable s | ||
, Typeable n | ||
) | ||
=> Maybe ApiWithdrawalPostData | ||
-> Handler (RewardAccountBuilder k) | ||
mkRewardAccountBuilder withdrawal = do | ||
let selfRewardCredentials (rootK, pwdP) = | ||
(getRawKey (deriveRewardAccount @k pwdP rootK), pwdP) | ||
=> ApiWithdrawalPostData | ||
-> Either ErrReadRewardAccount (RewardAccountBuilder k) | ||
shelleyOnlyRewardAccountBuilder w = | ||
case testEquality (typeRep @s) (typeRep @(SeqState n ShelleyKey)) of | ||
Nothing -> liftHandler $ throwE ErrReadRewardAccountNotAShelleyWallet | ||
Just Refl -> case withdrawal of | ||
Nothing -> pure selfRewardCredentials | ||
Just w -> case w of | ||
SelfWithdrawal -> pure selfRewardCredentials | ||
ExternalWithdrawal (ApiMnemonicT m) -> do | ||
let (xprv, _acct, _path) = W.someRewardAccount @ShelleyKey m | ||
pure (const (xprv, mempty)) | ||
Nothing -> throwError ErrReadRewardAccountNotAShelleyWallet | ||
Just Refl -> case w of | ||
SelfWithdrawal -> pure selfRewardAccountBuilder | ||
ExternalWithdrawal (ApiMnemonicT m) -> do | ||
let (xprv, _acct, _path) = W.someRewardAccount @ShelleyKey m | ||
pure (const (xprv, mempty)) | ||
|
||
selfRewardAccountBuilder | ||
:: forall k | ||
. ( HardDerivation k | ||
, Bounded (Index (AddressIndexDerivationType k) (AddressCredential k)) | ||
, WalletKey k | ||
) | ||
=> RewardAccountBuilder k | ||
selfRewardAccountBuilder (rootK, pwdP) = | ||
(getRawKey (deriveRewardAccount @k pwdP rootK), pwdP) |
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.
Thinking loudly: these are only used from the "old" tx endpoints for the sake of W.buildAndSignTransaction
, so we should eventually be able to remove/re-work into some clearer form. I think external withdrawals is what constructTx
wouldn't handle automatically, and if it wants to continue being unaware of them, perhaps something like this could work:
postTransactionOld = do
tx <- signTx wallet
$ addVkWitness externalWithdrawalKey -- after balancing
$ balanceTx wallet
$ addWithdrawal externalWithdrawal -- before balancing
$ constructUnbalancedTx payment
...
(conceptually)
bors r+ |
3555: Refactor in preparation to reuse `balanceTransaction` within `quitStakePool`. r=Unisay a=Unisay - [x] I did [rename Cardano.Wallet.Shelley.Pools to Cardano.Wallet.Pools](3af3732) because `Cardano.Wallet.Shelly` namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation. - [x] split one `mkRewardAccountBuilder` function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about. - [x] removed `queryRewardBalance` function as it adds no value on top of the `getCachedRewardAccountBalance`. (The PR is optimized for reviewing commit-by-commit) ### Issue Number In preparation to ADP-2267 Co-authored-by: Yura Lazarev <[email protected]>
Build failed: |
e552b8c
to
b08c8be
Compare
bors r+ |
3555: Refactor in preparation to reuse `balanceTransaction` within `quitStakePool`. r=Unisay a=Unisay - [x] I did [rename Cardano.Wallet.Shelley.Pools to Cardano.Wallet.Pools](3af3732) because `Cardano.Wallet.Shelly` namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation. - [x] split one `mkRewardAccountBuilder` function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about. - [x] removed `queryRewardBalance` function as it adds no value on top of the `getCachedRewardAccountBalance`. (The PR is optimized for reviewing commit-by-commit) ### Issue Number In preparation to ADP-2267 Co-authored-by: Yura Lazarev <[email protected]>
Build failed: |
bors retry |
a8a2027
to
eee2269
Compare
bors r+ |
3555: Refactor in preparation to reuse `balanceTransaction` within `quitStakePool`. r=Unisay a=Unisay - [x] I did [rename Cardano.Wallet.Shelley.Pools to Cardano.Wallet.Pools](3af3732) because `Cardano.Wallet.Shelly` namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation. - [x] split one `mkRewardAccountBuilder` function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about. - [x] removed `queryRewardBalance` function as it adds no value on top of the `getCachedRewardAccountBalance`. (The PR is optimized for reviewing commit-by-commit) ### Issue Number In preparation to ADP-2267 Co-authored-by: Yura Lazarev <[email protected]>
Build failed: |
bors merge |
3555: Refactor in preparation to reuse `balanceTransaction` within `quitStakePool`. r=Unisay a=Unisay - [x] I did [rename Cardano.Wallet.Shelley.Pools to Cardano.Wallet.Pools](3af3732) because `Cardano.Wallet.Shelly` namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation. - [x] split one `mkRewardAccountBuilder` function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about. - [x] removed `queryRewardBalance` function as it adds no value on top of the `getCachedRewardAccountBalance`. (The PR is optimized for reviewing commit-by-commit) ### Issue Number In preparation to ADP-2267 Co-authored-by: Yura Lazarev <[email protected]>
Build failed: |
bors merge |
3555: Refactor in preparation to reuse `balanceTransaction` within `quitStakePool`. r=Unisay a=Unisay - [x] I did [rename Cardano.Wallet.Shelley.Pools to Cardano.Wallet.Pools](3af3732) because `Cardano.Wallet.Shelly` namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation. - [x] split one `mkRewardAccountBuilder` function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about. - [x] removed `queryRewardBalance` function as it adds no value on top of the `getCachedRewardAccountBalance`. (The PR is optimized for reviewing commit-by-commit) ### Issue Number In preparation to ADP-2267 Co-authored-by: Yura Lazarev <[email protected]>
Build failed: |
bors r+ |
Build succeeded: |
…saction` within `quitStakePool`. r=Anviking a=Unisay - [x] I did [rename Cardano.Wallet.Shelley.Pools to Cardano.Wallet.Pools](3af3732) because `Cardano.Wallet.Shelly` namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation. - [x] split one `mkRewardAccountBuilder` function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about. - [x] removed `queryRewardBalance` function as it adds no value on top of the `getCachedRewardAccountBalance`. (The PR is optimized for reviewing commit-by-commit) ### Issue Number In preparation to ADP-2267 Co-authored-by: Yura Lazarev <[email protected]> Source commit: a3e6478
3583: Revise error name to `WithdrawalNotBeneficial`. r=jonathanknowles a=jonathanknowles ## Issue Number None. Noticed while reviewing #3555. ## Description This PR renames `ErrWithdrawalNotWorth` to `ErrWithdrawalNotBeneficial`. The wording of the former error name is broken. We _can_ say "a withdrawal is not worth **it**", but saying something is "not worth" (without the "it") just doesn't make sense in English. ## Compatibility Usages of the JSON error code `withdrawal_not_worth` are very rare: [Usages of `withdrawal_not_worth`](https://github.com/search?q=org%3Ainput-output-hk+%22withdrawal_not_worth%22&type=code). These rare cases can easily be updated with a tiny PR or two. Co-authored-by: Jonathan Knowles <[email protected]>
…`. r=jonathanknowles a=jonathanknowles ## Issue Number None. Noticed while reviewing #3555. ## Description This PR renames `ErrWithdrawalNotWorth` to `ErrWithdrawalNotBeneficial`. The wording of the former error name is broken. We _can_ say "a withdrawal is not worth **it**", but saying something is "not worth" (without the "it") just doesn't make sense in English. ## Compatibility Usages of the JSON error code `withdrawal_not_worth` are very rare: [Usages of `withdrawal_not_worth`](https://github.com/search?q=org%3Ainput-output-hk+%22withdrawal_not_worth%22&type=code). These rare cases can easily be updated with a tiny PR or two. Co-authored-by: Jonathan Knowles <[email protected]> Source commit: d59b05e
Cardano.Wallet.Shelly
namespace is a leftover from the times we had 2 separate libraries (core/shelley). It makes sense to me to gradually remove this separation.mkRewardAccountBuilder
function into smaller ones (corresponding to individual concers) as it had to many responsibilities at once, was hard to reason about.queryRewardBalance
function as it adds no value on top of thegetCachedRewardAccountBalance
.(The PR is optimized for reviewing commit-by-commit)
Issue Number
In preparation to ADP-2267