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

Use ticking function to get blocks #52

Closed
4 of 6 tasks
rvl opened this issue Mar 13, 2019 · 3 comments
Closed
4 of 6 tasks

Use ticking function to get blocks #52

rvl opened this issue Mar 13, 2019 · 3 comments
Assignees

Comments

@rvl
Copy link
Contributor

rvl commented Mar 13, 2019

Context

We have:

The ticking function should call the function to get blocks.

Decision

Add a function to get blocks every tick and log them.

startBlockSyncer
    :: MonadChainProducer m
    => NetworkName
    -> Port
    -> m ()

This function will be called from main and won't normally return.

Acceptance Criteria

  1. Must be able to catch up with blocks from chain producer.
  2. Must process (by logging to stdout) the blocks received.

Development Plan

  • Implement startBlockSyncer
  • Call startBlockSyncer from main`
  • Add iohk-monitoring-framework and use the basic set up which they have documented. (Maybe not yet -- haven't decided)
  • Log new blocks at "info" level
  • Rely on an externally launched cardano-http-bridge
  • Reflect upon design of the receive and process blocks feature, and propose then implement changes.

PR

Number Base
#54 master
#63 master
#52 master
#71 master

QA

  • Okay, we do now connect and receives blocks from the http bridge, pretty much epoch per epoch. Note that this is very very rudimentary for now and we are missing quite a few features coming soon:

    • Ability to persist the progression (ideally, we do want to process blocks as we fetch them, and store the latest tip we've processed).
    • Handling rollbacks and duplicates
  • Still, this can be manually tested by starting the current "wallet server" alongside the http bridge. Provided you've installed in cardano-http-bridge (cargo install https://github.com/input-output-hk/cardano-http-bridge.git):

cardano-http-bridge start --port 1337 & 
stack exec -- cardano-wallet-server --http-bridge-port 1337

This should print all blocks received from the http bridge, until the tip block is reached, whereupon a network block should be printed every 20 seconds.

  • Also, check what happens if the node backend crashes (or gets killed).
@rvl rvl self-assigned this Mar 13, 2019
@rvl rvl mentioned this issue Mar 13, 2019
3 tasks
@KtorZ
Copy link
Member

KtorZ commented Mar 13, 2019

Add iohk-monitoring-framework and use the basic set up which they have documented. (Maybe not yet -- haven't decided)

We need to discuss that further before going to far with this :)
This is almost a U/S on its own and requires proper thoughts, pros and cons, etc..

@rvl
Copy link
Contributor Author

rvl commented Mar 13, 2019

This [logging] is almost a U/S on its own and requires proper thoughts, pros and cons, etc..

Sure, agreed.

@KtorZ KtorZ self-assigned this Mar 14, 2019
KtorZ added a commit that referenced this issue Mar 15, 2019
…er-with-network-layer

Merge BlockSyncer with NetworkLayer
@piotr-iohk
Copy link
Contributor

lgtm 👍
I was able to connect and get blocks from mainnet and testnet:

  1. Mainnet: Run cardano-http-bridge with cargo run --release -- start --port 1337 --template mainnet and wallet with stack exec -- cardano-wallet-server --network mainnet --http-bridge-port 1337
  2. Testnet: Run cardano-http-bridge with cargo run --release -- start --port 1337 --template testnet and wallet: stack exec -- cardano-wallet-server --network testnet --http-bridge-port 1337

It seems that it is really not a lot of effort to also be able to connect from wallet to staging (as cardano-http-bridge seems to offer that as well): cargo run --release -- start --port 1337 --template staging

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

No branches or pull requests

3 participants