[Bug] Rollback subgraph automatically if it lands on a fork when connected to Firehose

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

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.
• I have searched the issue tracker to make sure this issue is not a duplicate.

OS information

Linux

Inizia tracciando il percorso FirehoseBlockStream indicato nei log e il modo in cui gestisce l’errore segnalato “cannot resolve cursor”. Determina come rilevare la perdita di un fork e provider Firehose in conflitto senza analizzare messaggi di testo. Il lavoro è completato quando il subgraph può scartare il proprio cursor e tornare in modo affidabile a known-final, con copertura delle modalità di errore segnalate.