The Firehose fork database is kept for a limited amount of time. Graph-node could be more intelligent and do that automatically when the fork can't be resolved.
Forks also don't resolve if you configure multiple firehose providers and one sees the fork and the other does not.
Graph Node needs to throw away its cursor in this case and reverts back to known-final, but we need guidance on how to reliably detect the error message. Having a specific error handling process would be a key requirement (without parsing text messages).
Relevant log output
Jan 22 04:15:32.485 ERRO Unable to connect to endpoint: status: Unknown, message: "transport error", details: [], metadata: MetadataMap { headers: {} }: transport error: operation was canceled: connection closed: connection closed, provider: firehose, deployment: QmSjgMiYaD3qPqhDBf3ody1wuwPRuD5iJjdxd3qTuxJ8Dj, sgd: 765, subgraph_id: QmSjgMiYaD3qPqhDBf3ody1wuwPRuD5iJjdxd3qTuxJ8Dj, component: FirehoseBlockStream
Jan 22 04:16:23.776 ERRO An error occurred while streaming blocks: status: InvalidArgument, message: "cannot resolve cursor: missing link between blocks 18962442 and #18962520 (48814e410c9313b9cb4562522cb18523c7840d7aba760498f50b61d4ccfcb655): no forked-block file found with ID ending with f50b61d4ccfcb655.", details: [], metadata: MetadataMap { headers: {} }, provider: firehose, deployment: QmSjgMiYaD3qPqhDBf3ody1wuwPRuD5iJjdxd3qTuxJ8Dj, sgd: 765, subgraph_id: QmSjgMiYaD3qPqhDBf3ody1wuwPRuD5iJjdxd3qTuxJ8Dj, component: FirehoseBlockStream
Jan 22 04:17:13.841 ERRO An error occurred while streaming blocks: status: InvalidArgument, message: "cannot resolve cursor: missing link between blocks 18962442 and #18962520 (48814e410c9313b9cb4562522cb18523c7840d7aba760498f50b61d4ccfcb655): no forked-block file found with ID ending with f50b61d4ccfcb655.", details: [], metadata: MetadataMap { headers: {} }, provider: firehose, deployment: QmSjgMiYaD3qPqhDBf3ody1wuwPRuD5iJjdxd3qTuxJ8Dj, sgd: 765, subgraph_id: QmSjgMiYaD3qPqhDBf3ody1wuwPRuD5iJjdxd3qTuxJ8Dj, component: FirehoseBlockStream
IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
[ ] Tick this box if this bug is caused by a regression found in the latest release.
[ ] Tick this box if this bug is specific to the hosted service.
[X] I have searched the issue tracker to make sure this issue is not a duplicate.
Bug report
The Firehose fork database is kept for a limited amount of time. Graph-node could be more intelligent and do that automatically when the fork can't be resolved.
Forks also don't resolve if you configure multiple firehose providers and one sees the fork and the other does not.
Graph Node needs to throw away its cursor in this case and reverts back to known-final, but we need guidance on how to reliably detect the error message. Having a specific error handling process would be a key requirement (without parsing text messages).
Relevant log output
IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
OS information
Linux