Triggers being hit before the specified startBlock

[0xSamWitch]

For this example I am querying the wrapped fantom contract with a much more recent startBlock :

  - kind: ethereum/contract
    name: WFTM
    network: fantom
    source:
      address: '0x21be370d5312f44cb42ce377bc9b8a0cef1a4c83'
      abi: ERC20
      startBlock: 31974159
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.4
      language: wasm/assemblyscript
      entities:
        # Just a dummy as seems required
        - User
      abis:
        - name: ERC20
          file: ../abis/ERC20.json
      eventHandlers:
        - event: Transfer(indexed address,indexed address,uint256)
          handler: handleTransfer
        - event: Approval(indexed address,indexed address,uint256)
          handler: handleApproval
      file: ../src/nfts/wftm.ts

I have other contracts which start earlier and in the logs I can see triggers happening (~5mil in this example) before the wftm startBlock (~32mil) is reached, this is causing massive slowdown in the subgraph processing as this is a very commonly used contract.

Apr 13 18:57:44 ip-172-31-5-123 sudo[1949561]: graph-node_1  | Apr 13 18:57:44.192 INFO 1 trigger found in this block for this subgraph, block_hash: 0x00001c680000098f73db197cf4a72a753a424d2c83d8905c48c2b0448155ae15, block_number: 5286905, sgd: 9, subgraph_id: QmZSN9XzbxzGXswqcPdRgRNnpii8v9yLfQeuhoAqUKPpDt, component: SubgraphInstanceManager

I would expect these triggers to not exist until after the startBlock specified.

[leoyvens]

To clarify, this logs 1 trigger found because the signature is being included in the eth_getLogs, but the trigger is not actually processed. It would be an optimization to not include this in the eth_geLogs call, but the ideal solution will be firehose integration, in this case for the fantom network.

[0xSamWitch]

To clarify, this logs 1 trigger found because the signature is being included in the eth_getLogs, but the trigger is not actually processed. It would be an optimization to not include this in the eth_geLogs call, but the ideal solution will be firehose integration, in this case for the fantom network.

Right it's not processed by the event handler, just heavily slowing down my sync by retrieving the logs unnecessarily

[passabilities]

any update on this?

seems like the issue has to do with theses lines of code:

graph-node/chain/ethereum/src/adapter.rs

Lines 637 to 638 in f41514f

	filter_opt.extend(Self {
	trigger_every_block: has_block_handler_without_filter,