-
Notifications
You must be signed in to change notification settings - Fork 217
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
Connect API with migration algorithm #2644
Connect API with migration algorithm #2644
Conversation
c651d40
to
f3c48e8
Compare
f3c48e8
to
5082eb6
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.
Will look closer later, but looks good 👍
@@ -193,7 +220,7 @@ spec = describe "SHELLEY_MIGRATIONS" $ do | |||
testAddressCycling 3 | |||
testAddressCycling 10 | |||
|
|||
Hspec.it "SHELLEY_MIGRATE_01_big_wallet - \ |
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 would not. Hspec.it
doesn't retry on failures. it
does retry, but the funds of the hard-coded mnemonic can only be spent once, most likely making it pointless.
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.
hoping we can remove the retrying it
soon
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.
That's interesting! I had no idea that this difference even existed. Thanks for pointing it out.
I'm just thinking how we could make this difference clearer, so that the name of the function makes it obvious whether or not the contents will be retried on failure.
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.
Fixed in d4f6fd6.
5082eb6
to
ababf43
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 seems pretty good so far 👍. You could also update the migration endpoint status info in swagger.yaml
. Unnecessary whitespace changes make it harder to provide a good review.
@@ -2310,6 +2413,11 @@ data ErrStartTimeLaterThanEndTime = ErrStartTimeLaterThanEndTime | |||
, errEndTime :: UTCTime | |||
} deriving (Show, Eq) | |||
|
|||
data ErrCreateMigrationPlan | |||
= ErrCreateMigrationPlanEmpty |
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.
Couldn't it just return and empty list of transactions? That seems fairly obvious and easy to handle for users.
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're right, it could.
However, the NothingToMigrate
condition was already a specific error in the old migrateWallet
API. This PR just reuses the same approach for createMigrationPlan
.
It covers two cases:
- The wallet is genuinely empty (therefore there really is nothing available to migrate).
- The wallet isn't empty, but the migration algorithm wasn't able to pay for any of the UTxO entries to be migrated, and therefore the plan is empty.
For the second case, I think it's useful to have a specific error here, as we can provide a useful hint to the user:
I wasn't able to construct a migration plan. This could be because your wallet is empty, or it could be because the amount of ada in your wallet is insufficient to pay for any of the funds to be migrated. Try adding some ada to your wallet before trying again."
For comparison, the original message was:
I can't migrate the wallet with the given ID, because it's either empty or full of small coins which wouldn't be worth migrating."
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.
Arguably it might want to be worth including the case-specific balanceLeftover
in the 403 case.
Could we have a err403 but returning ApiWalletMigrationPlan
with selections = []
? It couldn't include an error message though, and perhaps a bit weird, so probably not.
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 we have a err403 but returning ApiWalletMigrationPlan with selections = []? It couldn't include an error message though, and perhaps a bit weird, so probably not.
In that specific case, the balanceLeftover
would be precisely the same as the wallet's balance. So perhaps it wouldn't be providing any more info than the user already has. (Presumably, they already know their balance, or can easily check it.)
-> MigrationPlan | ||
-> Maybe (ApiWalletMigrationPlan n) | ||
mkApiWalletMigrationPlan s addresses rewardWithdrawal plan | ||
| Just selections <- maybeSelections = |
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.
case maybeSelections of
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 yes, the pattern guard is a bit unnecessary here!
(I think it might be a hangover from a previous version of the function.)
I've fixed this in a671d6e.
[ expectResponseCode HTTP.status202 | ||
, expectField | ||
(#totalFee . #getQuantity) | ||
(`shouldBe` 2_460_400) |
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.
In integration tests, exact values like this may cause us pain in future.
It might be possible to make the test case more forgiving of changes, without reducing its effectiveness.
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 @rvl. I think I understand your concerns here.
However, I think there are good arguments in favour of using exact values:
-
The new migration algorithm is completely deterministic: the plan is fully determined by the current UTxO, with no randomness. So if we start with the same fixture wallet and transaction constraints, we should always end up with precisely the same plan.
-
To increase confidence that there are no flaky tests, I've run the entire migration integration test suite 500 times and confirmed that it always passes.
-
Stating exact values means we can increase our confidence that the API is producing plans with reasonable fees, since fees are explicitly encoded as literals in the test code. I think it's good to be a bit paranoid here, as the potential cost to a user of miscalculating a fee is that they spend more ada than required (potentially without noticing).
-
If someone alters the fixture wallet definitions or the fee calculation algorithm, then it will cause the tests to fail. However, they're likely to fail in an extremely obvious way, and it's likely that we can fix them very quickly just by entering new numbers. It also gives a fresh chance for a human pair of eyes to confirm that fees produced by the API are reasonable.
5111544
to
d6771ce
Compare
If such a test fails when run the first time, it's more than likely that it'll fail when run a second time (as a fixture wallet's funds can only be spent once). In response to review feedback: #2644 (comment)
If such a test fails when run the first time, it's more than likely that it'll fail when run a second time (as a fixture wallet's funds can only be spent once). In response to review feedback: #2644 (comment)
7ada448
to
aef4f52
Compare
If such a test fails when run the first time, it's more than likely that it'll fail when run a second time (as a fixture wallet's funds can only be spent once). In response to review feedback: #2644 (comment)
In response to review feedback: #2644 (comment)
aef4f52
to
a671d6e
Compare
In response to review feedback: #2644 (comment)
bors try |
tryBuild succeeded: |
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.
👍
(`shouldBe` 255_200) | ||
, expectField (#selections) | ||
((`shouldBe` 1) . length) | ||
, expectField (#balanceSelected . #ada . #getQuantity) | ||
(`shouldBe` 1_000_000_000_000) | ||
, expectField (#balanceLeftover . #ada . #getQuantity) | ||
(`shouldBe` 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.
👍
lib/core/src/Cardano/Wallet.hs
Outdated
@@ -17,6 +17,7 @@ | |||
{-# LANGUAGE TypeApplications #-} | |||
{-# LANGUAGE TypeFamilies #-} | |||
{-# LANGUAGE TypeOperators #-} | |||
{-# OPTIONS_GHC -fno-warn-redundant-constraints #-} |
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.
☝️ Guessing your HLS quick-fix added this by mistake
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 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.
@Anviking Thanks, this is a good suggestion. 👍🏻
I also had reservations about disabling this warning. It's a shame that it's not possible to disable these warnings for just a single function. (Or is it?) I notice that we disable this warning in other modules -- perhaps we shouldn't do that.
I agree with you that it's just simpler to use a type synonym here.
I've fixed this in b913667.
@@ -2310,6 +2413,11 @@ data ErrStartTimeLaterThanEndTime = ErrStartTimeLaterThanEndTime | |||
, errEndTime :: UTCTime | |||
} deriving (Show, Eq) | |||
|
|||
data ErrCreateMigrationPlan | |||
= ErrCreateMigrationPlanEmpty |
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.
Arguably it might want to be worth including the case-specific balanceLeftover
in the 403 case.
Could we have a err403 but returning ApiWalletMigrationPlan
with selections = []
? It couldn't include an error message though, and perhaps a bit weird, so probably not.
Supplying an empty list of addresses would make it impossible to perform a migration.
This check is actually already performed in other integration tests. In addition, we can easily add this check to the end of tests that don't have it already.
If such a test fails when run the first time, it's more than likely that it'll fail when run a second time (as a fixture wallet's funds can only be spent once). In response to review feedback: #2644 (comment)
In response to review feedback: #2644 (comment)
In response to review feedback: #2644 (comment)
This allows us to remove the module-wide `fno-warn-redundant-constraints`. In response to review feedback: #2644 (comment)
2069746
to
b913667
Compare
bors r+ |
2644: Connect API with migration algorithm r=jonathanknowles a=jonathanknowles # Issue Number ADP-840 # Overview This PR: - [x] Implements `Api.Server.createWalletMigrationPlan`. - [x] Implements `Api.Server.migrateWallet`. - [x] Adjusts `migrateWallet` to require a non-empty list of addresses. - [x] Adjusts the success response types for all migration endpoints to be `202` `ACCEPTED`. - [x] Resurrects all previously-disabled integration tests (for ada-specific wallets). - [x] Removes the "disabled" warnings on migration endpoints. - [x] Adds integration test coverage for MA wallets. # QA Due Diligence After rewriting the integration test suite, I ran the entire integration test suite 500 times in an effort to increase confidence that there are no flaky tests. The test suite passed 500 times, with no failures or errors. Co-authored-by: Jonathan Knowles <[email protected]>
Build failed: Failure: Failures:
test/unit/Network/Wai/Middleware/LoggingSpec.hs:118:9:
1) Network.Wai.Middleware.Logging, Logging Middleware, GET, 200, no query
uncaught exception: HttpException
HttpExceptionRequest Request {
host = "localhost"
port = 63839
secure = False
requestHeaders = []
path = "/get"
queryString = ""
method = "GET"
proxy = Nothing
rawBody = False
redirectCount = 10
responseTimeout = ResponseTimeoutDefault
requestVersion = HTTP/1.1
}
ConnectionTimeout
To rerun use: --match "/Network.Wai.Middleware.Logging/Logging Middleware/GET, 200, no query/"
Randomized with seed 1332915072 |
bors r+ |
2644: Connect API with migration algorithm r=jonathanknowles a=jonathanknowles # Issue Number ADP-840 # Overview This PR: - [x] Implements `Api.Server.createWalletMigrationPlan`. - [x] Implements `Api.Server.migrateWallet`. - [x] Adjusts `migrateWallet` to require a non-empty list of addresses. - [x] Adjusts the success response types for all migration endpoints to be `202` `ACCEPTED`. - [x] Resurrects all previously-disabled integration tests (for ada-specific wallets). - [x] Removes the "disabled" warnings on migration endpoints. - [x] Adds integration test coverage for MA wallets. # QA Due Diligence After rewriting the integration test suite, I ran the entire integration test suite 500 times in an effort to increase confidence that there are no flaky tests. The test suite passed 500 times, with no failures or errors. Co-authored-by: Jonathan Knowles <[email protected]>
Build failed: Failure:
This looks superficially similar to the following issue, but it seems as though the underlying cause is the node disappearing. (Perhaps that issue also has the same underlying cause.) |
bors r+ |
Build succeeded: |
2644: Connect API with migration algorithm r=jonathanknowles a=jonathanknowles # Issue Number ADP-840 # Overview This PR: - [x] Implements `Api.Server.createWalletMigrationPlan`. - [x] Implements `Api.Server.migrateWallet`. - [x] Adjusts `migrateWallet` to require a non-empty list of addresses. - [x] Adjusts the success response types for all migration endpoints to be `202` `ACCEPTED`. - [x] Resurrects all previously-disabled integration tests (for ada-specific wallets). - [x] Removes the "disabled" warnings on migration endpoints. - [x] Adds integration test coverage for MA wallets. # QA Due Diligence After rewriting the integration test suite, I ran the entire integration test suite 500 times in an effort to increase confidence that there are no flaky tests. The test suite passed 500 times, with no failures or errors. Co-authored-by: Jonathan Knowles <[email protected]> a60199f
2651: Testing shared wallets r=piotr-iohk a=piotr-iohk # Issue Number ADP-866 # Overview - 73225b4 fix e2e tests to comply with purpose=1854' for multisig keys - c475917 Tests for cosigner self - ed846f0 Tests for public keys - 40698f4 Tests for Account Public Keys # Comments 2652: Test migration of SeaHorses failing due to insufficient ada r=Anviking a=Anviking # Issue Number <!-- Put here a reference to the issue that this PR relates to and which requirements it tackles. Jira issues of the form ADP- will be auto-linked. --> #2644 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] Remove `pendingWith` to enable `SHELLEY_CREATE_MIGRATION_PLAN_04 - Cannot create a plan for a wallet that only contains dust.` - [x] Fund the source wallet with SeaHorses and as small amount of ada to make the migration fail # Comments <!-- Additional comments or screenshots to attach if any --> <!-- 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) ✓ Jira will detect and link to this PR once created, but you can also link this PR in the description of the corresponding ticket ✓ Acknowledge any changes required to the Wiki ✓ Finally, in the PR description delete any empty sections and all text commented in <!--, so that this text does not appear in merge commit messages. --> Co-authored-by: Piotr Stachyra <[email protected]> Co-authored-by: Johannes Lund <[email protected]>
Issue Number
ADP-840
Overview
This PR:
Api.Server.createWalletMigrationPlan
.Api.Server.migrateWallet
.migrateWallet
to require a non-empty list of addresses.202
ACCEPTED
.QA Due Diligence
After rewriting the integration test suite, I ran the entire integration test suite 500 times in an effort to increase confidence that there are no flaky tests. The test suite passed 500 times, with no failures or errors.