Feature Request: Improve envio indexer to support start_block and end_block per datasource

[Simon0x]

Hello envio team,

I'd like to ask to have the option to specify an start_block and end_block per datasource rather than per network.
An example use case for us for example is that we have a PropertyFactory that is registering new tokenized properties on the chain. Lets say this is PropertyFactoryV1. Now we deploy a new PropertyFactory, call it PropertyFactoryV2 that will only be used from now on.

This could become very hand in case of upgradeable proxies, where you might push an update that change the signature of the underlying events. In this case you could specify the same proxy contract address with two different handlers as you have a start and end block per handler.
This idea comes from my usage with subgraphs where it was possible. Example of how it was done there:

specVersion: 0.0.4
description: Gravatar for Ethereum
repository: https://github.com/graphprotocol/graph-tooling
schema:
  file: ./schema.graphql
indexerHints:
  prune: auto
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      abi: Gravity
      startBlock: 6175244
      endBlock: 7175245
    context:
      foo:
        type: Bool
        data: true
      bar:
        type: String
        data: 'bar'
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.6
      language: wasm/assemblyscript
      entities:
        - Gravatar
      abis:
        - name: Gravity
          file: ./abis/Gravity.json
      eventHandlers:
        - event: NewGravatar(uint256,address,string,string)
          handler: handleNewGravatar
        - event: UpdatedGravatar(uint256,address,string,string)
          handler: handleUpdatedGravatar
      callHandlers:
        - function: createGravatar(string,string)
          handler: handleCreateGravatar
      blockHandlers:
        - handler: handleBlock
        - handler: handleBlockWithCall
          filter:
            kind: call
      file: ./src/mapping.ts

[JonoPrest]

Hey @Simon0x,

Thanks for noting all of these features in issues!

Just to unblock you for your use case with upgradeable proxies, we do provide a way to add an "name" alias for an event where the signature has changed.

So for instance you can have:

    events:
      - event: NewGravatar(uint256,address,string,string)
      - event: NewGravatar(uint256,address)
        name: NewGravatarUpgraded

You can then write a different handler for "NewGravatar" and "NewGravatarUpgraded" event though they share the same underlying event name (so long as the signature is indeed different).

And write different handlers for these events. It even works if you add/update "indexed" parameters

[Simon0x]

Thanks for the information. I still think we should add this, in case of different factory contracts that can be deployed.

[JonoPrest]

Thanks for the information. I still think we should add this, in case of different factory contracts that can be deployed.

Got you 👍🏼 I think it's a good idea and it's been suggested before. It's not trivial to implement but definitely possible and if there is use case for it then it's worthwhile.

The main advantage I see is that you wouldn't include stale events in your queries for logs, making the indexer slightly leaner.

Are you saying that, in your example of a factory that gets upgraded, you would want it to stop indexing the factory created contracts that were previously registered from that factory?

[Simon0x]

Yes. So for example we might have a factory that creates PropertyTokensV1, then we decide to upgrade the entire protocol to issue PropertyTokensV2. In this case I'd like to simply have an option to specify a end_block for the old factory.

Or lets say you use Chainlink oracles. On Ethereum mainnet they have a Registry for it but on other networks not. What they do quite often is that they at one point say that a certain contracts is the new feed. In that case I want to have end_block defined for feeds that are from now on inactive.