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.

Sign up for GitHub

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

Jump to bottom

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

Closed
6 tasks done
jonathanknowles opened this issue Oct 11, 2019 · 1 comment
Closed
6 tasks done

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

jonathanknowles opened this issue Oct 11, 2019 · 1 comment
Assignees
@jonathanknowles
Milestone
Byron Wallet Support

Comments

@jonathanknowles
Copy link
Member

jonathanknowles commented Oct 11, 2019 •
edited
Loading

Context

The compatibility API server (which supports operations on Byron-style wallets) will require access to two contexts:

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

Decision

Fork the existing API server context into two separate contexts, as described above. The compatibility API server should be given a definition similar to:

compatibilityApiServer
    :: forall t . 
        ( Buildable (ErrValidateSelection t)  
        , DefineTx t  
        , KeyToAddress t RndKey   
        , KeyToAddress t SeqKey   
        ) 
    => ApiLayer (RndState t) t RndKey 
    -> ApiLayer (SeqState t) t SeqKey 
    -> Server (CompatibilityApi t)
compatibilityApiServer               rndCtx seqCtx
    =    deleteByronWallet           rndCtx  
    :<|> getByronWallet              rndCtx
    :<|> getByronWalletMigrationInfo rndCtx   
    :<|> listByronWallets            rndCtx  
    :<|> migrateByronWallet          rndCtx seqCtx 
    :<|> postByronWallet             rndCtx

Most operations on this API will only require access to the random context, but the migrateByronWallet operation will require access to both contexts.

Acceptance Criteria

  • The random context must only provide access to Byron-style wallets.
  • The sequential context must only provide access to new-style wallets.
  • It should be possible to discriminate at the file-system level between random wallet
    databases and sequential wallet databases.

QA

Build integration tests to verify that:

  • Calling the createWallet API function results in a database file with the seq prefix.
  • Calling the createByronWallet API function results in a database file with the rnd prefix.
  • Calling the listWallets API function only lists wallets whose database filenames have the seq prefix.
  • Calling the listByronWallets API function only lists wallets whose database filenames have the rnd prefix.
  • Calling the getWallet API function with a wallet ID that corresponds to a Byron wallet returns a wallet not found error.
  • Calling the getByronWallet API function with a wallet ID that corresponds to a new-style wallet returns a wallet not found error.

PR

Number Base
#809 master
#810 master
#846 master
@jonathanknowles jonathanknowles added this to the Byron Wallet Support milestone Oct 11, 2019
@jonathanknowles jonathanknowles self-assigned this Oct 11, 2019
@jonathanknowles jonathanknowles changed the title Fork API context into random and sequential. Fork API server context into random and sequential variants. Oct 11, 2019
This was referenced Oct 11, 2019
Merged
Merged
iohk-bors bot added a commit that referenced this issue Oct 14, 2019
@iohk-bors @jonathanknowles
Merge #809
424124f 
809: Provide `KeyToAddress` instance for `(Jormungandr n) RndKey` type. r=jonathanknowles a=jonathanknowles

# Issue Number

#808 

# Overview

This PR provides a missing `KeyToAddress` instance for the `(Jormungandr n) RndKey` type.

It's identical to the instance provided within `cardano-http-bridge`, namely for the `(HttpBridge 'Mainnet) RndKey` type.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Oct 14, 2019
@iohk-bors @jonathanknowles @KtorZ
Merge #810 #816
ba62ce5 
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 bot added a commit that referenced this issue Oct 14, 2019
@iohk-bors @jonathanknowles
Merge #810
ae2a62c 
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 bot added a commit that referenced this issue Oct 15, 2019
@iohk-bors @jonathanknowles
Merge #810
19a7f4b 
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]>
@piotr-iohk
Copy link
Contributor

lgtm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jonathanknowles jonathanknowles

Labels
None yet
Projects
None yet
Milestone
Byron Wallet Support
Development

No branches or pull requests
2 participants
@jonathanknowles @piotr-iohk