-
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
actually identify output by their transaction AND output index... #1697
Conversation
Hmm I will investigate the generators for the state machine tests. |
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.
Maybe simple integration test checking that sum of inputs >= sum of outputs of the sent tx could be also handy.
The transaction id doesn't uniquely identify an output! So, if a transaction had several output, they'd all be conflated under the same key... 🤦
3b780e5
to
ee35bdb
Compare
bors r+ |
bors r- |
1697: actually identify output by their transaction AND output index... r=KtorZ a=KtorZ # Issue Number <!-- Put here a reference to the issue this PR relates to and which requirements it tackles --> #1670 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> The transaction id doesn't uniquely identify an output! So, if a transaction had several output, they'd all be conflated under the same key... 🤦 I wonder why the state machine didn't catch that though.. because the database model was doing it correctly by using the full `TxIn` as a key. # 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) ✓ Once created, link this PR to its corresponding ticket ✓ Assign the PR to a corresponding milestone ✓ Acknowledge any changes required to the Wiki --> Co-authored-by: KtorZ <[email protected]> Co-authored-by: Piotr Stachyra <[email protected]>
Canceled |
@@ -847,6 +847,14 @@ scenario_TRANS_REG_1670 fixture = it title $ \ctx -> do | |||
Empty | |||
|
|||
-- ASSERTIONS | |||
let transaction = head $ getFromResponse id rTxs |
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.
@piotr-iohk There's no guarantee that the first tx is the one we are interested in here 🤔
It'll be safer to simply run this check for every transaction present in the wallet, it should hold anyway.
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.
Added verification for all outgoing transactions -> f8bcfe2. Incoming txs not necessarily have input amounts.
bors r+ |
Build succeeded |
Issue Number
#1670
Overview
The transaction id doesn't uniquely identify an output! So, if a transaction had several output, they'd all be conflated under the same key... 🤦
I wonder why the state machine didn't catch that though.. because the database model was doing it correctly by using the full
TxIn
as a key.Comments