Fix Change Calculation (#286) #292

KtorZ · 2019-05-21T07:42:39Z

Issue Number

Overview

I have extended our test to capture the issue highlighted in the bug
I have looked at the test failing
I have fixed the calculation of the change which was... weirdly way off the specification..

Comments

KtorZ · 2019-05-21T07:43:42Z

lib/core/src/Cardano/Wallet/Primitive/Model.hs

-changeUTxO proxy pending = evalState $ do
-    ourUtxo <- mapM (state . utxoOurs proxy) (Set.toList pending)
-    let ins = txIns pending
-    return $ fold ourUtxo `restrictedBy` ins


Not even sure why this was even there... The spec says:

Which is exactly what the first line already does... The two others are non-sense.

KtorZ · 2019-05-21T07:44:11Z

lib/http-bridge/test/integration/Test/Integration/Scenario/Transactions.hs

            [ expectSuccess
            , expectEventually ctx balanceAvailable (oneMillionAda + 1)
            ]
+
+        verify ra
+            [ expectEventually ctx balanceAvailable 999999831346


I really love this expectEventually combinator 😄 ....

jonathanknowles · 2019-05-21T07:49:37Z

lib/http-bridge/test/integration/Test/Integration/Scenario/Transactions.hs

            [ expectSuccess
            , expectEventually ctx balanceAvailable (oneMillionAda + 1)
            ]
+
+        verify ra
+            [ expectEventually ctx balanceAvailable 999999831346


Hi @KtorZ
Where does this 999999831346 value come from, exactly, and what is its significance? Assuming it's supposed to be the same value as https://git.io/fj4GR, then would it be clearer to use a named constant, possibly with a comment to state its origin?

All fixture wallets have exactly 1000M ADA on them (should be 1M though, but will fix in another PR). So, this amount is 1000M - cost of the last payment. Can make them constants :)

jonathanknowles · 2019-05-21T09:19:10Z

lib/http-bridge/test/integration/Test/Integration/Framework/DSL.hs

+oneMillionAda :: Natural
+oneMillionAda = ada (1_000_000)
+  where
+    ada = (*) (1_000_000)


I wonder if it would be possible to use the type system here, to distinguish amounts (in Ada or Lovelace) from other values that happen to be Natural?

In particular, we're trying to encode something that is a number of Lovelace: the number of lovelace in one Ada.

We could use Quantity etc ... But we purposely use raw types in the integration DSL to keep the test scenarios readable and simple to write.

that's was my question : why not Quantity here?

As just explained, to avoid having to perform to many transformations when writing the integration test scenarios. Scenarios are mostly just about submitting things to the API and asserting results; Manipulating raw types directly there makes it very easy to write these scenarios and piggy-back on the API to do the type-checking etc ...

More importantly, it also allows us to provide invalid and out-of-range values and still submit them to test that API fulfill its role! This is also why we don't use a typed client in the integration tests. We do want to be able to submit invalid values :)

Besides, Quantity might not always help. Consider

pay :: Quantity "lovelace" Natural -> result -- later do pay (Quantity 100) ...

The type is inferred at the call-site and can easily be confused. Would be better to enforce it to be explicit.

Like

do pay (Lovelace 100) ...

(I'm sure there are fancier ways too)

jonathanknowles · 2019-05-21T09:19:42Z

lib/http-bridge/test/integration/Test/Integration/Scenario/Transactions.hs


        r <- request @ApiTransaction ctx ("POST", postTx wa) Default payload
        verify r
            [ expectSuccess
            , expectResponseCode HTTP.status202
-            , expectFieldEqual amount 168654
+            , expectFieldEqual amount (fee + amt)


This is much clearer. I like it 👍

jonathanknowles · 2019-05-21T09:19:54Z

lib/http-bridge/test/integration/Test/Integration/Scenario/Transactions.hs

            , expectFieldEqual direction Outgoing
            , expectFieldEqual status Pending
            ]

        ra <- request @ApiWallet ctx ("GET", getWallet wa) Default payload
        verify ra
            [ expectSuccess
-            , expectFieldEqual balanceTotal 999999831346
+            , expectFieldEqual balanceTotal (oneMillionAda - fee - amt)


jonathanknowles · 2019-05-21T09:20:12Z

lib/http-bridge/test/integration/Test/Integration/Scenario/Transactions.hs

            ]

        verify ra
-            [ expectEventually ctx balanceAvailable 999999831346
+            [ expectEventually ctx balanceAvailable (oneMillionAda - fee - amt)


paweljakubas · 2019-05-21T09:24:43Z

lib/http-bridge/test/integration/Test/Integration/Framework/DSL.hs

@@ -430,7 +432,7 @@ fixtureWallet ctx@(Context _ _ _ faucet) = do
        Left _ -> fail "fixtureWallet: waited too long for initial transaction"
        Right a -> return a
  where
-    oneSecond = 1*1000*1000
+    oneSecond = 1_000_000


we do not want Quantity here? maybe it is overstreatch here, but we use second through the code (I believe) and maybe it is not silly idea to introduce time units somewhere. and if so rely on Quantity there

paweljakubas

LGTM! I see that shuffle (one red test detected it) haunts us also here ;-) After #295 we should be confident it is not to happen again

KtorZ · 2019-05-21T10:56:39Z

bors r+

283: Sqlite: add checkpoints and transactions to DBLayer r=KtorZ a=rvl Relates to issue #154. # Overview - Implemented saving and loading of transaction history to SQLite - Implemented saving and loading of wallet checkpoints to SQLite, including the state for sequential scheme address discovery. # Comments - The SqliteSpec testing is a bit light. However, there should be enough implemented for all the DBSpec tests to work. Also I plan to finish the QSM tests tomorrow which should provide even more coverage. - Cascading deletes are not working with persistent-sqlite, which is annoying. - DB indexes are missing on some fields. (Needs some custom SQL, can be fixed later) 289: show feature availability in API specification r=KtorZ a=KtorZ # Issue Number  N/A # Overview  - [ ] I have removed the"priority" from the specification and added a "status" indicating the availability of a particular feature in the API. # Comments  As requested by Chris. Makes it easier for externals to know what's available or not. A preview: ![image](https://user-images.githubusercontent.com/5680256/58074137-bdc26f00-7ba4-11e9-95b5-33ff723e0f2a.png) ![image](https://user-images.githubusercontent.com/5680256/58074150-c6b34080-7ba4-11e9-83a5-943877e14fd7.png) ![image](https://user-images.githubusercontent.com/5680256/58074161-cfa41200-7ba4-11e9-8d83-0948b129e856.png) ![image](https://user-images.githubusercontent.com/5680256/58074177-dd599780-7ba4-11e9-867e-5047012b1f93.png) ![image](https://user-images.githubusercontent.com/5680256/58074188-e5193c00-7ba4-11e9-845c-cacfd34a9fc9.png)  292: Fix Change Calculation (#286) r=KtorZ a=KtorZ # Issue Number  #286 # Overview  - [x] I have extended our test to capture the issue highlighted in the bug - [x] I have looked at the test failing - [x] I have fixed the calculation of the change which was... weirdly way off the specification.. # Comments   Co-authored-by: Rodney Lorrimar <rodney.lorrimar@iohk.io> Co-authored-by: Pawel Jakubas <pawel.jakubas@iohk.io> Co-authored-by: KtorZ <matthias.benkort@gmail.com>

KtorZ · 2019-05-21T11:56:51Z

bors r+

283: Sqlite: add checkpoints and transactions to DBLayer r=KtorZ a=rvl Relates to issue #154. # Overview - Implemented saving and loading of transaction history to SQLite - Implemented saving and loading of wallet checkpoints to SQLite, including the state for sequential scheme address discovery. # Comments - The SqliteSpec testing is a bit light. However, there should be enough implemented for all the DBSpec tests to work. Also I plan to finish the QSM tests tomorrow which should provide even more coverage. - Cascading deletes are not working with persistent-sqlite, which is annoying. - DB indexes are missing on some fields. (Needs some custom SQL, can be fixed later) 289: show feature availability in API specification r=KtorZ a=KtorZ # Issue Number  N/A # Overview  - [ ] I have removed the"priority" from the specification and added a "status" indicating the availability of a particular feature in the API. # Comments  As requested by Chris. Makes it easier for externals to know what's available or not. A preview: ![image](https://user-images.githubusercontent.com/5680256/58074137-bdc26f00-7ba4-11e9-95b5-33ff723e0f2a.png) ![image](https://user-images.githubusercontent.com/5680256/58074150-c6b34080-7ba4-11e9-83a5-943877e14fd7.png) ![image](https://user-images.githubusercontent.com/5680256/58074161-cfa41200-7ba4-11e9-8d83-0948b129e856.png) ![image](https://user-images.githubusercontent.com/5680256/58074177-dd599780-7ba4-11e9-867e-5047012b1f93.png) ![image](https://user-images.githubusercontent.com/5680256/58074188-e5193c00-7ba4-11e9-845c-cacfd34a9fc9.png)  292: Fix Change Calculation (#286) r=KtorZ a=KtorZ # Issue Number  #286 # Overview  - [x] I have extended our test to capture the issue highlighted in the bug - [x] I have looked at the test failing - [x] I have fixed the calculation of the change which was... weirdly way off the specification.. # Comments   296: Improve bech32 coveralls r=KtorZ a=piotr-iohk # Issue Number  # Overview  - [ ] I have replaced `isLeft` with `Left ...` here and there to improve coveralls score a bit # Comments   Co-authored-by: Rodney Lorrimar <rodney.lorrimar@iohk.io> Co-authored-by: Pawel Jakubas <pawel.jakubas@iohk.io> Co-authored-by: KtorZ <matthias.benkort@gmail.com> Co-authored-by: Piotr Stachyra <piotr.stachyra@iohk.io>

piotr-iohk

👍

KtorZ · 2019-05-21T12:50:53Z

bors retry

292: Fix Change Calculation (#286) r=KtorZ a=KtorZ # Issue Number  #286 # Overview  - [x] I have extended our test to capture the issue highlighted in the bug - [x] I have looked at the test failing - [x] I have fixed the calculation of the change which was... weirdly way off the specification.. # Comments   Co-authored-by: KtorZ <matthias.benkort@gmail.com>

KtorZ requested a review from piotr-iohk May 21, 2019 07:42

KtorZ self-assigned this May 21, 2019

KtorZ commented May 21, 2019

View reviewed changes

jonathanknowles reviewed May 21, 2019

View reviewed changes

KtorZ added 3 commits May 21, 2019 11:12

reproduce bug #286

fa80c12

fix change UTxO calculation

37daa16

use constants instead of hard-coded numbers in Transactions Scenarios

252cd12

KtorZ force-pushed the KtorZ/286/fix-change-calculation branch from d380903 to 252cd12 Compare May 21, 2019 09:12

jonathanknowles reviewed May 21, 2019

View reviewed changes

paweljakubas reviewed May 21, 2019

View reviewed changes

paweljakubas approved these changes May 21, 2019

View reviewed changes

piotr-iohk approved these changes May 21, 2019

View reviewed changes

KtorZ merged commit a015aff into master May 21, 2019

iohk-bors bot deleted the KtorZ/286/fix-change-calculation branch May 21, 2019 13:17

piotr-iohk mentioned this pull request May 22, 2019

Total and available balance are reported as 0 until transaction gets into ledger #286

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix Change Calculation (#286) #292

Fix Change Calculation (#286) #292

KtorZ commented May 21, 2019 •

edited

Loading

KtorZ May 21, 2019

KtorZ May 21, 2019

jonathanknowles May 21, 2019

KtorZ May 21, 2019

jonathanknowles May 21, 2019

KtorZ May 21, 2019

paweljakubas May 21, 2019

KtorZ May 21, 2019

Anviking May 21, 2019

jonathanknowles May 21, 2019

jonathanknowles May 21, 2019

jonathanknowles May 21, 2019

paweljakubas May 21, 2019 •

edited

Loading

paweljakubas left a comment

KtorZ commented May 21, 2019

KtorZ commented May 21, 2019

piotr-iohk left a comment

KtorZ commented May 21, 2019

Fix Change Calculation (#286) #292

Fix Change Calculation (#286) #292

Conversation

KtorZ commented May 21, 2019 • edited Loading

Issue Number

Overview

Comments

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paweljakubas May 21, 2019 • edited Loading

Choose a reason for hiding this comment

paweljakubas left a comment

Choose a reason for hiding this comment

KtorZ commented May 21, 2019

KtorZ commented May 21, 2019

piotr-iohk left a comment

Choose a reason for hiding this comment

KtorZ commented May 21, 2019

KtorZ commented May 21, 2019 •

edited

Loading

paweljakubas May 21, 2019 •

edited

Loading