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

chore: use the latest substreams version #18

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ppoliani
Copy link
Contributor

No description provided.

@@ -14,10 +14,11 @@ start:
firehose-real-time-tolerance: 999999999s
relayer-max-source-latency: 999999999s

common-live-blocks-addr: ""
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@maoueh if I don't set this to empty string then when I run

    grpcurl -plaintext -import-path ../proto -import-path ./proto -proto sf/aptos/type/v1/type.proto -proto sf/firehose/v2/firehose.proto -d '{"start_block_num": 0}' localhost:18015 sf.firehose.v2.Stream.Blocks

I get the following error:

Failed to dial target host "localhost:18015": dial tcp [::1]:18015: connect: connection refused

This was not the case before I updated the substreams version.

I did debug it a and realized that this value is set the flow get stuck at select https://github.com/streamingfast/firehose/blob/develop/app/firehose/app.go#L183 and doesn't reach the launch line https://github.com/streamingfast/firehose/blob/develop/app/firehose/app.go#L193.

Is there a reason why this happens with the latest substreams version?

Copy link
Contributor

Choose a reason for hiding this comment

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

This code in firehose component that wait for the hub to be "live" exist since a long time, definitely not coming from an upgrade of the dependency alone.

But I think the way we detect it changed indeed. Now you need to have one-blocks files that "links" with live blocks coming from the live source which means syncing a testnet will be ready only once blocks are live.

Since this is syncing devnet, I imagine it will indeed not work anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ow you need to have one-blocks files that "links" with live blocks coming from the live source which means syncing a testnet will be ready only once blocks are live.

Pardon my ignorance, but I'm not sure I fully understand this concepts 😆

one-blocks are the files stored locally, right? From what I've notices, this is files are created when the console reader gets the logs from the stdout and decodes the block data which are then stored. So what does this sentence mean?

syncing a testnet will be ready only once blocks are live.

Doe sit mean that the endpoint on port :18015 will be available once the full network is synced?

Copy link
Contributor

@maoueh maoueh left a comment

Choose a reason for hiding this comment

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

Do you want me to merge that now?

@@ -14,10 +14,11 @@ start:
firehose-real-time-tolerance: 999999999s
relayer-max-source-latency: 999999999s

common-live-blocks-addr: ""
Copy link
Contributor

Choose a reason for hiding this comment

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

This code in firehose component that wait for the hub to be "live" exist since a long time, definitely not coming from an upgrade of the dependency alone.

But I think the way we detect it changed indeed. Now you need to have one-blocks files that "links" with live blocks coming from the live source which means syncing a testnet will be ready only once blocks are live.

Since this is syncing devnet, I imagine it will indeed not work anymore.

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