-
Notifications
You must be signed in to change notification settings - Fork 3
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
base: main
Are you sure you want to change the base?
chore: use the latest substreams version #18
Conversation
@@ -14,10 +14,11 @@ start: | |||
firehose-real-time-tolerance: 999999999s | |||
relayer-max-source-latency: 999999999s | |||
|
|||
common-live-blocks-addr: "" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this 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: "" |
There was a problem hiding this comment.
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.
No description provided.