Skip to content
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

Fork API server context into random and sequential variants. #810

Merged
merged 9 commits into from
Oct 15, 2019

Conversation

jonathanknowles
Copy link
Member

@jonathanknowles jonathanknowles commented Oct 11, 2019

Issue Number

#808

Overview

This PR forks the API server context into two variants:

  1. a random context that corresponds to Byron wallets.
  2. a sequential context that corresponds to Shelley wallets.

Remaining Work

  • Discriminate between random and sequential wallets at the file-system level.

@jonathanknowles
Copy link
Member Author

bors try

iohk-bors bot added a commit that referenced this pull request Oct 11, 2019
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 11, 2019

try

Build succeeded

@jonathanknowles jonathanknowles force-pushed the jonathanknowles/split-context branch 2 times, most recently from 5ecfe69 to c40e7e2 Compare October 14, 2019 13:24
@jonathanknowles jonathanknowles marked this pull request as ready for review October 14, 2019 13:24
@jonathanknowles
Copy link
Member Author

bors try

iohk-bors bot added a commit that referenced this pull request Oct 14, 2019
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 14, 2019

try

Build succeeded

@@ -14,6 +14,8 @@
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}

{-# OPTIONS_GHC -fno-warn-redundant-constraints #-}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which one are they 🤔 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which one are they?

I added this simply to avoid having to remove all the (currently unnecessary) constraints from Byron skeleton functions only to have to add them again when we fill in the function definitions (which will then require the constraints again).

-> FilePath
-> IO [W.WalletId]
findDatabases tr dir = do
files <- listDirectory dir
fmap catMaybes $ forM files $ \file -> do
isFile <- doesFileExist (dir </> file)
let (basename:rest) = T.splitOn "." $ T.pack file
let (prefix : basename : rest) = T.splitOn "." $ T.pack file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now a partial function that may fail. We are sure that T.splitOn pattern txt will always return at least one element (the argument itself) but not necessarily two! In particular, if there's a file that isn't named with a prefix, this will crash badly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great observation. I had assumed that the original function was partial, and that (therefore) we didn't mind.

I'll remove the partiality.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one was partial-safe haha. Perhaps that should be in our coding standard actually. Always add a comment to justify why a unsafe usage might actually be safe in some context. Here, that's my bad for not adding this comment. I usually do, but well, that's something we should be careful with.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KtorZ wrote:

Always add a comment to justify why a unsafe usage might actually be safe in some context.

Agreed!

I've made another change which should have removed the partiality. Though let me know if you require any further changes.

@@ -395,6 +395,10 @@ class WalletKey (key :: Depth -> * -> *) where
=> key depth XPub
-> Digest a

-- | Get a short, human-readable string descriptor that uniquely identifies
-- the specified key type.
keyTypeDescriptor :: Proxy key -> String
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

This instance is identical to that of the `(HttpBridge 'Mainnet) RndKey` type.
For `(Jormungandr n) RndKey` type.

Note that this property is lifted directly from:

lib/http-bridge/test/unit/Cardano/Wallet/HttpBridge/CompatibilitySpec.hs
(present at commit: 117186d)
Clarify comments and names of function arguments so that they clearly
refer to either a database directory (containing database files) or a
single database file.
…pes.

We use the prefix "rnd" to denote database files of wallets where the
address derivation style is random.

We use the prefix "seq" to denote database files of wallets where the
address derivation style is sequential.
@jonathanknowles jonathanknowles force-pushed the jonathanknowles/split-context branch from c40e7e2 to 042e52b Compare October 14, 2019 15:39
@jonathanknowles
Copy link
Member Author

bors try

iohk-bors bot added a commit that referenced this pull request Oct 14, 2019
@KtorZ
Copy link
Member

KtorZ commented Oct 14, 2019

bors r+

iohk-bors bot added a commit that referenced this pull request Oct 14, 2019
810: Fork API server context into random and sequential variants. r=KtorZ a=jonathanknowles

# Issue Number

#808 

# Overview

This PR forks the API server context into two variants:

1. a _**random**_ context that corresponds to _**Byron**_ wallets. 
2. a _**sequential**_ context that corresponds to _**modern**_ wallets.

# Remaining Work

- [x] Discriminate between _**random**_ and _**sequential**_ wallets at the file-system level.

816: Network information endpoint r=KtorZ a=KtorZ

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->

N/A

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [x] I have renamed 'WalletState' to 'SyncProgress', for we'll also use this in the network information endpoint and.. it truly is just about the syncing progress.

- [x] I have reviewed the swagger specification network information endpoint to better reflect the information we're going to return. Basically, the `localBlockchainHeight` does not make much sense for us at this level, because there's actually a local height per wallet. So this information will better be located in each wallets directly.

- [x] Added a field `pendingSince` for transactions. I shouldn't have done that in this PR but I did it as I was updating the swagger. This is not related to the networking endpoint so it might get a little confusing in the review.

- [x] I've also re-generated all the golden API tests because I was getting a lot of warnings about files not being up-to-date (nothing to do with this PR but it seems that we haven't updated them along the way....)

# Comments

<!-- Additional comments or screenshots to attach if any -->

Some screenshot of the swagger specification:

![Screenshot from 2019-10-14 12-09-15](https://user-images.githubusercontent.com/5680256/66757422-72cf2e00-ee9c-11e9-8740-8063689c0985.png)

![Screenshot from 2019-10-14 12-06-26](https://user-images.githubusercontent.com/5680256/66757428-75ca1e80-ee9c-11e9-82f4-6c90c723e9cd.png)

<!-- 
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
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: Jonathan Knowles <[email protected]>
Co-authored-by: KtorZ <[email protected]>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 14, 2019

try

Build succeeded

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 14, 2019

Build failed (retrying...)

iohk-bors bot added a commit that referenced this pull request Oct 14, 2019
810: Fork API server context into random and sequential variants. r=KtorZ a=jonathanknowles

# Issue Number

#808 

# Overview

This PR forks the API server context into two variants:

1. a _**random**_ context that corresponds to _**Byron**_ wallets. 
2. a _**sequential**_ context that corresponds to _**modern**_ wallets.

# Remaining Work

- [x] Discriminate between _**random**_ and _**sequential**_ wallets at the file-system level.

Co-authored-by: Jonathan Knowles <[email protected]>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 14, 2019

Build failed

@jonathanknowles
Copy link
Member Author

bors r+

iohk-bors bot added a commit that referenced this pull request Oct 15, 2019
810: Fork API server context into random and sequential variants. r=jonathanknowles a=jonathanknowles

# Issue Number

#808 

# Overview

This PR forks the API server context into two variants:

1. a _**random**_ context that corresponds to _**Byron**_ wallets. 
2. a _**sequential**_ context that corresponds to _**modern**_ wallets.

# Remaining Work

- [x] Discriminate between _**random**_ and _**sequential**_ wallets at the file-system level.

Co-authored-by: Jonathan Knowles <[email protected]>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Oct 15, 2019

Build succeeded

@iohk-bors iohk-bors bot merged commit 26c5866 into master Oct 15, 2019
@KtorZ KtorZ deleted the jonathanknowles/split-context branch October 16, 2019 12:11
@KtorZ KtorZ added this to the Byron Wallet Support milestone Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants