Open DenisCarriere opened 1 year ago
@DenisCarriere I think this is currently expected behaviour (rather than a bug), the substreams package dictates the starting block. I can see the argument for setting this in the subgraph.yaml
, but I can also see potential confusion arising with the same setting in two places. I guess interested in thinking through the different permutations:
Maybe it might be cleanest if the startBlock overrides the initialBlock (e.g. as a parameter), but that could also be troublesome if there are different initialBlocks across different modules? @maoueh interested in your thoughts here
I agree that it's currently a feature. I also agree that the source of truth will be the .spkg
and that subgraph start block < substreams start block should be forbidden if we ever allow startBlock
in the Subgraph manifest.
What is the use case here exactly you tried to achieve @DenisCarriere? Testing purposes I imagine?
Which packages are impacted by your issue?
@graphprotocol/graph-cli
Describe the issue
Cannot provide
startBlock: 1397553
for when using Substreams data source.Reproduction
https://github.com/pinax-network/substreams-cookbook/tree/main/erc20
Steps to Reproduce the Bug or Issue
Error message:
Expected behavior
Additionally to Substreams
startBlock
, should be able to providestartBlock
to Subgraph when using Substreams data source.Screenshots or Videos
No response
Platform
$ graph --version @graphprotocol/graph-cli/0.51.2 darwin-arm64 node-v20.2.0
Subgraph Manifest
not sure where to include:
startBlock: 1397553
Subgraph GraphQL Schema
No response
Additional context
Alternative way, must provide
initialBlock: 1397553
toSubstreams.yaml