-
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
Add prop_balanceTransactionBalanced #2996
Conversation
2b6baeb
to
0bb51d6
Compare
{ getFeePolicy = mockFeePolicy | ||
, getTxMaxSize = Quantity 16384 | ||
, getTokenBundleMaxSize = TokenBundleMaxSize $ TxSize 4000 | ||
, getMaxExecutionUnits = ExecutionUnits 10000000 10000000000 | ||
} | ||
, minimumUTxOvalue = MinimumUTxOValue $ Coin 1000000 |
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.
Suggestion: use NumericUnderscores
for large values such as these.
87bc8ff
to
12e2320
Compare
8564d8e
to
8abd7a1
Compare
@@ -433,7 +432,7 @@ instance Arbitrary SlotNo where | |||
arbitrary = genSlotNo | |||
|
|||
genLovelaceCoverage :: Lovelace -> Property | |||
genLovelaceCoverage = unsignedCoverage (maxBound @Word16) "lovelace" | |||
genLovelaceCoverage = unsignedCoverage (maxBound @Word32) "lovelace" |
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.
Lovelace
is unbounded — is having to pass in a Word32 bound weird?
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 is just bad UX on my part. You don't need to pass in the maxBound of the unsigned you are testing the coverage of, but you do need to pass in some value that the test can use to delineate between "large" and "small" values (with things above the value being considered large).
I'm not really happy with this code.
$ classify (txFee sealedTx > Cardano.Lovelace 1_000_000) | ||
"fee above 1 ada" | ||
(txBalance sealedTx combinedUTxO === 0) | ||
.&&. (abs (txFee sealedTx) .<= 4_000_000) |
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.
TODO: Test fee >= minFee
but also not too much of an over-estimate. Perhaps another property (and definitely another PR/ticket)
9ee89ad
to
71865b0
Compare
bors try |
tryBuild failed: |
47ef500
to
de9b123
Compare
bors try |
tryBuild failed: |
dcd74d5
to
f154313
Compare
bors try |
tryBuild failed: |
f154313
to
7854206
Compare
bors try |
Thanks for your work on this Johannes 🎉 I think I'm ok with this, as long as my understanding of it is correct: This is a first step in fixing bugs with the current balanceTransaction implementation. I'm not sure how I feel about the coverage of the generators (which is my fault too!), but that's unimportant I think. The important thing is that the generators and the test have found issues, and we should use these going forward to fix the implementation of balance transaction. I have one unimportant suggestion here: #3052, but otherwise, looks good! |
Using a not-yet-committed prop_balanceTransactionBalanced it was discovered that balanceTransaction would produce imbalanced transactions under several scenarios. The guards/preconditions added here ensure the limitations are clear to users who run into them. It also makes the limitations clearly known and documented, allowing us to come up with an appropriate strategy to fix.
34c3640
to
32bc654
Compare
- Tests that balanceTransaction produces balanced results - Decent shrinking and failure-presentation - Used to discover the preconditions added in a prev commit - Generator coverages of some corner cases are missing - empty txIns - empty txOuts - gens never cause balanceTransaction to select collateral for some reason (!) - PParams are currently static - In-the-end marked pending because of a new variable-length-coin-encoding corner cases
- Make the semantics of "Maybe Coin" more obvious by using a descriptive data type.
Co-authored-by: Samuel Evans-Powell <[email protected]>
32bc654
to
f5bf2a1
Compare
Thanks! Yes, this is a first step! bors r+ |
2996: Add prop_balanceTransactionBalanced r=Anviking a=Anviking ## Overview - Add preconditions to `balanceTransaction` such that we fail instead of producing imbalanced results... - when there are withdrawals with different network tags - when there are deposits or refunds (pool reg, stake key reg/dereg) (apparently not pool retirement) - when collateral is pre-selected - when we underestimate the fee (likely related to variable length coin encoding and the padding) - Tweak generators in `Cardano.Api.Gen` - Add (pending) `prop_balanceTransactionBalanced` - Decent shrinking and failure-presentation - Used to discover the preconditions above - Generator coverages of some corner cases are missing - empty txIns - empty txOuts - gens never cause balanceTransaction to select collateral for some reason (!) - PParams are currently static - In-the-end marked pending because of a new variable-length-coin-encoding corner cases ## Comments The problems we theorised during the coarse first implementation are indeed caught by the property (collateral, fee encoding corner cases, deposits), which is nice. Discovering additional problems was nice too. While the coverage is still not ideal, I believe it's good enough to give re-writing the implementation a go. ### Issue Number ADP-1214 <!-- 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: Johannes Lund <[email protected]> Co-authored-by: Samuel Evans-Powell <[email protected]>
Build failed: |
bors r+ |
2996: Add prop_balanceTransactionBalanced r=Anviking a=Anviking ## Overview - Add preconditions to `balanceTransaction` such that we fail instead of producing imbalanced results... - when there are withdrawals with different network tags - when there are deposits or refunds (pool reg, stake key reg/dereg) (apparently not pool retirement) - when collateral is pre-selected - when we underestimate the fee (likely related to variable length coin encoding and the padding) - Tweak generators in `Cardano.Api.Gen` - Add (pending) `prop_balanceTransactionBalanced` - Decent shrinking and failure-presentation - Used to discover the preconditions above - Generator coverages of some corner cases are missing - empty txIns - empty txOuts - gens never cause balanceTransaction to select collateral for some reason (!) - PParams are currently static - In-the-end marked pending because of a new variable-length-coin-encoding corner cases ## Comments The problems we theorised during the coarse first implementation are indeed caught by the property (collateral, fee encoding corner cases, deposits), which is nice. Discovering additional problems was nice too. While the coverage is still not ideal, I believe it's good enough to give re-writing the implementation a go. ### Issue Number ADP-1214 <!-- 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: Johannes Lund <[email protected]> Co-authored-by: Samuel Evans-Powell <[email protected]>
Build failed: Due to renaming of cardano-ledger-specs repo |
bors r+ |
2996: Add prop_balanceTransactionBalanced r=Anviking a=Anviking ## Overview - Add preconditions to `balanceTransaction` such that we fail instead of producing imbalanced results... - when there are withdrawals with different network tags - when there are deposits or refunds (pool reg, stake key reg/dereg) (apparently not pool retirement) - when collateral is pre-selected - when we underestimate the fee (likely related to variable length coin encoding and the padding) - Tweak generators in `Cardano.Api.Gen` - Add (pending) `prop_balanceTransactionBalanced` - Decent shrinking and failure-presentation - Used to discover the preconditions above - Generator coverages of some corner cases are missing - empty txIns - empty txOuts - gens never cause balanceTransaction to select collateral for some reason (!) - PParams are currently static - In-the-end marked pending because of a new variable-length-coin-encoding corner cases ## Comments The problems we theorised during the coarse first implementation are indeed caught by the property (collateral, fee encoding corner cases, deposits), which is nice. Discovering additional problems was nice too. While the coverage is still not ideal, I believe it's good enough to give re-writing the implementation a go. ### Issue Number ADP-1214 <!-- 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: Johannes Lund <[email protected]> Co-authored-by: Samuel Evans-Powell <[email protected]>
Build failed:
|
bors r+ |
2996: Add prop_balanceTransactionBalanced r=Anviking a=Anviking ## Overview - Add preconditions to `balanceTransaction` such that we fail instead of producing imbalanced results... - when there are withdrawals with different network tags - when there are deposits or refunds (pool reg, stake key reg/dereg) (apparently not pool retirement) - when collateral is pre-selected - when we underestimate the fee (likely related to variable length coin encoding and the padding) - Tweak generators in `Cardano.Api.Gen` - Add (pending) `prop_balanceTransactionBalanced` - Decent shrinking and failure-presentation - Used to discover the preconditions above - Generator coverages of some corner cases are missing - empty txIns - empty txOuts - gens never cause balanceTransaction to select collateral for some reason (!) - PParams are currently static - In-the-end marked pending because of a new variable-length-coin-encoding corner cases ## Comments The problems we theorised during the coarse first implementation are indeed caught by the property (collateral, fee encoding corner cases, deposits), which is nice. Discovering additional problems was nice too. While the coverage is still not ideal, I believe it's good enough to give re-writing the implementation a go. ### Issue Number ADP-1214 <!-- 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: Johannes Lund <[email protected]> Co-authored-by: Samuel Evans-Powell <[email protected]>
Build failed: |
bors r+ |
Build succeeded: |
Overview
balanceTransaction
such that we fail instead of producing imbalanced results...Cardano.Api.Gen
prop_balanceTransactionBalanced
Comments
The problems we theorised during the coarse first implementation are indeed caught by the property (collateral, fee encoding corner cases, deposits), which is nice. Discovering additional problems was nice too.
While the coverage is still not ideal, I believe it's good enough to give re-writing the implementation a go.
Issue Number
ADP-1214