Home / Input Output / cardano-wallet
284 commits this week Jan 12, 2020 - Jan 19, 2020

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

use latest available genesis config for ALL migration tests

Use the genesis block from the latest release only. Having different genesis block (hash) across releases will basically make all wallets incompatible with each others. Prior to now workers would simply loop ad-infinitum trying to rollback to (0, 0).

Now, workers would simply exit complaining about a different genesis hash. To work around this, we use the same genesis configuration for all nodes in the migration tests, so that the hash remains the same across all tests.

use latest available genesis config for ALL migration tests

Use the genesis block from the latest release only. Having different genesis block (hash) across releases will basically make all wallets incompatible with each others. Prior to now workers would simply loop ad-infinitum trying to rollback to (0, 0).

Now, workers would simply exit complaining about a different genesis hash. To work around this, we use the same genesis configuration for all nodes in the migration tests, so that the hash remains the same across all tests.

use latest available genesis config for ALL migration tests

Use the genesis block from the latest release only. Having different genesis block (hash) across releases will basically make all wallets incompatible with each others. Prior to now workers would simply loop ad-infinitum trying to rollback to (0, 0).

Now, workers would simply exit complaining about a different genesis hash. To work around this, we use the same genesis configuration for all nodes in the migration tests, so that the hash remains the same across all tests.

Merge #1266

1266: Add a manual DB migration step for active_slot_coeff. r=KtorZ a=jonathanknowles

Issue Number

#1251

Overview

This PR:

  • [x] Adds the ability to perform manual DB migration actions after connecting to a SQLite database.
  • [x] Uses this ability to detect whether or not the active_slot_coeff field is present in the checkpoint table.
  • [x] Adds the active_slot_coeff field manually, if it was not present already, using a default value that is passed down from the network layer.
  • [ ] Figure out the cause of repeated log entries of the form:
[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Try rolling back to 0.0
[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Rolled back to 0.0

Comments

Co-authored-by: Jonathan Knowles [email protected] Co-authored-by: KtorZ [email protected]

Merge #1266

1266: Add a manual DB migration step for active_slot_coeff. r=KtorZ a=jonathanknowles

Issue Number

#1251

Overview

This PR:

  • [x] Adds the ability to perform manual DB migration actions after connecting to a SQLite database.
  • [x] Uses this ability to detect whether or not the active_slot_coeff field is present in the checkpoint table.
  • [x] Adds the active_slot_coeff field manually, if it was not present already, using a default value that is passed down from the network layer.
  • [ ] Figure out the cause of repeated log entries of the form:
[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Try rolling back to 0.0
[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Rolled back to 0.0

Comments

Co-authored-by: Jonathan Knowles [email protected] Co-authored-by: KtorZ [email protected]

Merge #1275

1275: Removing lenses from integration tests (state, addressPoolGap, balance*) r=KtorZ a=piotr-iohk

Issue Number

#1237

Overview

  • b43b949ffa63acf4e7f8a7d88da0d7df92dc1844 Remove addressPoolGap lens

  • 24d318ca75b8eccf732f1b0bfbbf01fde4944e92 Remove state lens

  • 446f7812916ca96380fb7f4946a4a057e6f7b634 Remove balance lenses: - byronBalanceAvailable - balanceAvailable - byronBalanceTotal - balanceTotal - balanceReward

  • 9d2e67981eeb63698dc69994c758013601e8802f get rid of duplicate magic constants

    • addressPoolGapMin
    • addressPoolGapMax
    • passphraseMinLength
    • passphraseMaxLength

Also got rid of an extra print statement that slipped through

Comments

Co-authored-by: Piotr Stachyra [email protected] Co-authored-by: KtorZ [email protected]

Merge #1259

1259: Calculate pool desirability according to delegation design spec r=Anviking a=Anviking

Issue Number

#1250

Overview

  • [x] New completely isolated module implementing ~nonMyopicMemberRewards~ desirability and related helper functions from the spec.
  • [x] Some simple unit/property tests as sanity checks

Comments

  • To be squashed before merging. Leaving a couple un-squashed for now, for history.

⬇️ Now reverted. Coming in a later PR! (Task #1276 )

Work in progress example ranking (without averaging, and with some hard-coded slightly off values)

Skärmavbild 2020-01-10 kl  18 46 39

With basic averaging (not exponential):

Skärmavbild 2020-01-10 kl  21 06 41

A newer screenshot (lots of 1PCT pools at the top now):

Skärmavbild 2020-01-13 kl  15 47 52

Co-authored-by: Johannes Lund [email protected] Co-authored-by: KtorZ [email protected]