[Bug] Subgraph with endBlock on all datasources keeps synching with unfiltered firehose request

[sduchesneau]

Bug report

When running a subgraph with a single datasource bounded by an 'endBlock', the subgraph will continue indexing forever passed that endBlock.

This is a costly operation if the graph-node is using firehose, because the filter will be EMPTY.

Either we should stop the indexing of the subgraph at that point, or just the blockstream, or at least, make sure that the firehose filters are set to "not match anything".

To reproduce:

• On a local graph-node, take an existing subgraph like this one:
  https://github.com/graphprotocol/graph-tooling/blob/main/examples/ethereum-basic-event-handlers/subgraph.yaml

• Apply these few changes:

+++ b/examples/ethereum-basic-event-handlers/subgraph.yaml
@@ -1,4 +1,4 @@
-specVersion: 0.0.5
+specVersion: 0.0.9
 description: Gravatar for Ethereum
 repository: https://github.com/graphprotocol/graph-tooling
 schema:
@@ -6,9 +6,11 @@ schema:
 dataSources:
   - kind: ethereum/contract
     name: Gravity
-    network: test
+    network: mainnet
     source:
-      address: '0x5FbDB2315678afecb367f032d93F642f64180aa3'
+      address: '0x2e645469f354bb4f5c8a05b3b30a929361cf77ec'
+      startBlock: 6175244
+      endBlock: 6175300
       abi: Gravity
     mapping:
       kind: ethereum/events

• stop it after a while and restart it.
• Observe this log:
  Blockstream disconnected, connecting, provider_err_count: 0, cursor: (...), start_block: 6243715, endpoint_uri: firehose, provider: firehose, deployment: Qmc5kz5vA4kXWDHmrvMXkxyTgEUX4xHNsNRWX5pnjSVcST, sgd: 1, subgraph_id: Qmc5kz5vA4kXWDHmrvMXkxyTgEUX4xHNsNRWX5pnjSVcST, component: FirehoseBlockStream

The issue with the firehose filter is here:
https://github.com/graphprotocol/graph-node/blob/v0.35.1/chain/ethereum/src/adapter.rs#L316-L318

A way to get around the issue would be to apply a "never-matching" filter, example by having a "log filter" with a single address of "0x0000000000000..."

But I'm wondering if the solution should be around the handling of the "end block" situation ?

Relevant log output

No response

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

None