Handlers and Filters

Sentio processors basically provide you with an event-driven model to handle and submit data. Once a processor is created, you can register your event handler functions with filters.

The handler function usually takes two parameters, the first one is data and the second one is the context. Data usually refers to the actual object that is selected by the handler. Context usually holds all the API objects such as meter, eventLogger and all the additional information such as block number, contract reference, etc.

For some handler types, you can pass a filter to significantly speed up your data processing.

EVM

  • onBlockInterval: executes on certain block intervals - X to backfill historical data, and executes every Y blocks when processing new data. Both X and Y are configurable.

  • onTimeInterval: executes on certain time intervals - X minutes to backfill historical data, and executes every Y minutes when processing new data. Both X and Y are configurable.

  • onEventXXX: executes on certain event occurrences of this contract. To have those handlers available, you need to code-gen your own types of processor, or use built-in processors, e.g., ERC20Processor.onEventApproval. You can filter events using event filters also generated for your contract. For example, for ApprovalEventFilter, you can create and use it as follows. Each parameter represents the desired value of the event, with undefined or null value meaning match all. The semantics is the same as Ethereum's own log filter; read more details here.

    const filter = ERC20Processor.filters.Approval(  '0x0000000000000000000000000000000000000000',  '0xb329e39ebefd16f40d38f07643652ce17ca5bac1')
    
    ERC20Processor.bind(...).onEventTransfer(...,
      filter
    )
    • onCallXXX: execute on certain function calls based on Ethereum traces. You need to code-gen the processor or use a builtin processor as well. An example call handler is ERC20Processor.onCallBurnFrom which captures all burn from calls. Notice you might need to check the error field before using the data to generate metrics.
    ERC20Processor.bind(...)
      .onCallBurnFrom((call, ctx) => {
         if (!call.error) {
           ctx.meter.Counter("burned").add(call.args.amount)
         }
      })
    • onAllEvent : execute on all types of event occurrences of this contract, usually use GenericProcessor when you don't want to use a full ABI JSON to do code gen.

Solana

TBD

Aptos

  • onTimeInterval: executes on certain time intervals - X minutes to backfill historical data, and executes every Y minutes when processing new data. Both X and Y are configurable.

  • onVersionInterval: executes on certain version intervals - X to backfill historical data, and executes every Y versions when processing new data. Both X and Y are configurable.

  • onEntryXXXFunction: executes on all of your specific entry function calls. The first argument is the payload of the function with fully decoded and typed arguments. Refer to coin.TransferPayload as an example. The second argument is AptosContext that holds APIs and additional information like the full user transaction. A full example looks like this:

    SouffleChefCampaign.bind({ startVersion: 6604913 })
      .onEntryPullTokenV2((call, ctx) => {
        ctx.meter.Counter('pulled').add(call.arguments_typed[3])
      })

    Note that by default it will only capture the successful entry function calls. If you also want to inspect the failed ones, you can pass an extra argument as follows. The failed transaction payload will not include the arguments_typed field, so you need to guard the access.

    SouffleChefCampaign.bind({ startVersion: 6604913 })
        .onEntryPullTokenV2((call, ctx) => {
        ...
      }, { incluedFailed: true })
  • onEventXXX: executes on all the specific event occurrences. Similar to the above handler, the first argument is the event data structure, e.g., coin.WithdrawEventInstance. The second argument is also the AptosContext. Note that the transaction object in event handler's context will not hold full transaction info. The event list and the entry function payload will be ignored. If you need those, then consider the function handler.

  • SouffleChefCampaign.bind({ startVersion: 6604913 })
      .onEventBurnEnjoyEvent((evt, ctx) => {
        ctx.meter.Counter('burned').add(1)
      })type

Aptos filters are still in development. We welcome your feedback through our telegram group.