hydra
Search…
Hydra Processor
Hydra processor is a client-side 'sink' tool used to fetch substrate events from a Hydra indexer. It sequentially applies the event handlers one by one in the order the events have been emitted.

Commands

hydra-processor help [COMMAND]

display help for hydra-processor
display help for <%= config.bin %>
USAGE
$ hydra-processor help [COMMAND]
ARGUMENTS
COMMAND command to show help for
OPTIONS
--all see all commands in CLI
See code: @oclif/plugin-help

hydra-processor migrate

undefined
USAGE
$ hydra-processor migrate
OPTIONS
-e, --env=env Path to a file with environment variables

hydra-processor run

undefined
USAGE
$ hydra-processor run
OPTIONS
-e, --env=env Path to a file with environment variables
-m, --manifest=manifest Manifest file
--id=id ID of the processor (useful for multi-processor setups)
--indexer=indexer Indexer URL to source events

Qickstart

Before the first run, the processor should set up auxiliary database tables required for its work:
hydra-processor migrate
Then hydra-processor can be run against the manifest file (by default, it looks up manifest.yml in the current folder)
hydra-processor run -m <path/to/manifest> -e <path to a file with env variables>

Environment variables

Hydra processor requires a manifest file and certain environment variables to be set.
Variable
Default
Required
Description
INDEXER_ENDPOINT_URL
-
Yes
Hydra indexer endpoint to source the raw event and extrinsic data
MANIFEST_PATH
manifest.yml
No
Path to the manifest file
DB_NAME
-
Yes
Database name
DB_PORT
-
Yes
Database port
DB_HOST
-
Yes
Database host
DB_USER
-
Yes
Database user
DB_PASS
-
Yes
Database password
PROMETHEUS_PORT
3000
No
A prometheus metrics endpoint is started at this port
POLL_INTERVAL_MS
1 sec (60000 msec)
No
How often the processor polls the indexer for new blocks
The required variables can either be set externally or loaded from a file using the -e flag, e.g.:
hydra-processor migrate -e .env

Manifest file

The manifest file describes which and how the events and extrinsics should be processed. Here is an example for Kusama blockchain:
version: '0.1'
description: Test manifest
repository: https://github.com/
## currently only these settings for the datasouce section are accepted
dataSource:
kind: substrate
chain: kusama
indexerVersion: '0.0.4'
# compiled model classes generated by hydra-cli codegen from the input schema
entities:
- mappings/lib/generated/**/*.model.js
mappings:
hydraCommonVersion: '0.0.3'
# process only blocks with height >= 1M
blockInterval: '[1000000,]'
# js module that exports the handler functions
mappingsModule: mappings/lib/mappings
# additinal libraries the processor loads
# typically it is a module with event and extrinsic types generated by hydra-typegen
imports:
- mappings/lib/mappings/generated/types
eventHandlers:
# event name
- event: balances.Transfer
# function handler name with the argument types
handler: balancesTransfer(DatabaseManager, Balances.TransferEvent)
extrinsicHandlers:
# infer defaults here
#- extrinsic: Balances.Transfer
#- extrinsic: Sudo.batchCall
# handler: handleSudoCall(DatabaseManager,SubstrateEvent)
preBlockHooks:
postBlockHooks: