Firehose only provider should be possible for Ethereum #4304
Labels
Comments
|
possibly related to #4059? |
|
Closing this as I believe it is now resolved, please re-open @maoueh if this is still live |
|
@azf20 is it really resolved that i need no RPC provider now? |
|
@matthewdarwin you still need a |
|
Seems that RPC providers will be needed until #4431 is resolved |
|
Yes you need an RPC provider for eth_call, but if you have no eth_call, then should not be needed. |
|
Doesn't seem to be resolved. Getting this error on latest version: Deployed subgraph doesn't make any eth calls and indexes if I uncomment RPC provider. Config: |
|
If you add Interestingly, if you add a "fake" So I guess it's not needed really, just need to fix that |
|
@azf20 Issue |
|
@maoueh @matthewdarwin @YaroShkvorets this is fixed on latest Master if you're able to test + verify (and thanks to @mangas) |
|
I'm stilling having trouble getting a Firehose only config working on a fresh database. The fresh database is important, if I add an RPC provider, it start working. If I revert back to the config shown below, it start working correctly. So it seems it happens really only when Firehose only config and fresh database. Tried on latest master this morning (commit ), using config: This leads to Logs |
|
This manifest differently when dealing with substreams only deployment: [general]
[store]
[store.primary]
connection = "postgresql://graph-node:let-me-in@localhost:5432/graph-node"
weight = 1
pool_size = 10
[chains]
ingestor = "block_ingestor_node"
[chains.mainnet]
shard = "primary"
provider = [
{ label = "firehose", details = { type = "firehose", url = "$SUBSTREAMS_ENDPOINT" }},
{ label = "substreams", details = { type = "substreams", url = "$SUBSTREAMS_ENDPOINT" }},
]
[deployment]
[[deployment.rule]]
shard = "primary"
indexers = [ "default" ]It actually panics at: Apr 12 15:07:12.918 DEBG Cleaning up large notifications after about 300s, channel: chain_head_updates, component: ChainHeadUpdateListener > NotificationListener
Apr 12 15:07:13.059 ERRO No store configured for Ethereum chain mainnet; ignoring this chain
thread 'tokio-runtime-worker' panicked at 'any substreams endpoint needs an rpc or firehose chain defined: no network mainnet found on chain ethereum', node/src/main.rs:742:18
stack backtrace:
0: ...
...
17: 0x1004b9328 - graph_node::ethereum_networks_as_chains::h61feb777cf9cd320
at /Users/maoueh/work/sf/graph-node/node/src/main.rs:740:31
18: 0x1004be1f0 - graph_node::main::{{closure}}::{{closure}}::{{closure}}::h738c82fc042a27d0
at /Users/maoueh/work/sf/graph-node/node/src/main.rs:337:31
19: 0x100e489bc - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::future::future::Future>::poll::h677d1053d1eea354
at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/panic/unwind_safe.rs:296:9
...But it seems to be the same problem as my other firehose report but with a different result. A workaround is to defined once an RPC provider, let it boot, close, restart with firehose/substreams only config, it works properly, I'm able to index a Substreams. Workaround:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
If only a Firehose provider is specified in the graph node config for an Ethereum chain, the chain is not wired correctly and will not be available for indexing.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
With this config:
No chain is available at all.
What is the expected behavior?
1 Ethereum
mainnetchain should be available.Details
Some hunting led me to create_ethereum_networks_for_chain. This function is what actually populate the initial
eth_networksthat is used later to connect to adapter and firehose endpoints.This function is however only looking for
web3provider, so if no RPC node is configured at all, the chain is not created as no provider is set up.The text was updated successfully, but these errors were encountered: