-
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
Enhance integration tests relating to transaction metadata and fees #2749
Enhance integration tests relating to transaction metadata and fees #2749
Conversation
This allows the test to be parameterized over different types of transaction metadata.
This allows it to be used from test cases in different modules.
This will allow it to be applied to different types of metadata.
3bdf00b
to
f2928e0
Compare
let apiCoinSelection = | ||
getFromResponse Prelude.id coinSelectionResponse | ||
let fee = computeApiCoinSelectionFee apiCoinSelection | ||
fee `shouldBe` Coin expectedFee |
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 check here if expectedFee
equals result of hand written computeApiCoinSelectionFee
, but might it be that Ledger hadrware device calculates it wrong?
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 check here if
expectedFee
equals result of hand writtencomputeApiCoinSelectionFee
, but might it be that Ledger hadrware device calculates it wrong?
Does the ledger hardware device perform its own fee computation, or adjust the ada quantities in any way?
I was under the impression that it just signs the the transaction provided to it.
lib/core-integration/src/Test/Integration/Scenario/API/Shelley/HWWallets.hs
Outdated
Show resolved
Hide resolved
2160509
to
a1eabdd
Compare
By doing this, we can confirm that the 'selectCoins' endpoint produces a selection whose fee is identical to the selection produced by the 'postTransaction' endpoint.
This allows us to compare the fees before and after adding metadata.
…allets`. Creating coin selections (with and without metadata) is now covered in: `Test.Integration.Scenario.API.Shelley.Transactions`.
a1eabdd
to
6abdb1f
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.
It seems that the issue was fixed by adding additional metadata entry so proper fee can be calculated on coin selection -> https://input-output-rnd.slack.com/archives/C819S481Y/p1625242073175000?thread_ts=1623941347.111200&cid=C819S481Y In any case these are very good additional tests! |
bors r+ |
Build succeeded: |
Issue Number
ADP-1009
Overview
This PR doesn't provide a solution for ADP-1009, but it does add integration test coverage relating to transaction metadata and fees.
In principle, the following two endpoints, if called on a wallet with the same starting UTxO and coin selection criteria, should return identical transaction fees (modulo random selection):
selectCoins
postTransaction
Modifications made by this PR
This PR:
TRANSMETA_CREATE_01
so that it tests with a variety of different coin selection criteria:TRANSMETA_CREATE_01
so that it first performs a dry-run coin selection with theselectCoins
endpoint.TRANSMETA_CREATE_01
so that it cross-checks the fee obtained from callingselectCoins
with the fee obtained from calling postTransaction, failing if the fees are not identical.This PR provides evidence that:
selectCoins
andpostTransaction
endpoints do generate selections with identical fees, provided the coin selection criteria are identical.