v0.15.0

CAUTION: If you are running your own Graph Node, make sure to run 0.14.0 for a week or two and deploy a new version of your subgraphs at least once before switching to 0.15.0. The 0.14.0 release gradually removes the public.entities table in favor of per-subgraph entities tables. Switching to 0.15.0 too early may break existing subgraphs and require you to redeploy and reindex immediately.

Fallible contract calls (#1139)

Calls to contract functions can fail due to assertions in the contract. Until now there was no way to handle this in subgraphs gracefully. This release introduces new try_someContractFunction call variants that return a result object with reverted and value fields. These can then be used in mappings to handle call failures.

An example can be found in the documentation.

Top-level templates (#1085)

Data source templates have been moved to a top-level templates field in the manifest. The data source templates documentation has been updated accordingly.

Top-level templates simplify creating new data sources at runtime: templates can now be referred to from all data sources and can create new data sources from other templates as well.

This also affects subgraph validation and code generation in a few ways. While Graph Node >= 0.15.0 still allows subgraphs with nested templates to run, Graph CLI now rejects such subgraphs. Code generation now puts all generated template classes into a single templates.ts file.

For more details, see the original issue.

Docker changes

• Set default Ethereum network name to mainnet in docker-compose.yml (#1086).
• Add setup.sh script for Linux host IP detection. Run this before the docker-compose up and it will inject the host IP address into docker-compose.yml (#1123).

Other changes

• Add support for arrays of Ethereum tuples / Solidity structs (#1119).
• Optimize performance of serializing data from Rust to AssemblyScript (#1145).
• Support decoding Ethereum strings with broken UTF-8 encoding (#1152).
• Bump default IPFS timeout to 60s (#1091).
• Fetch blocks from Ethereum if loading them from the cache fails (#1108).
• Reduce memory usage of filtering blocks with call traces (#1110).
• Add GRAPH_TOKIO_THREAD_COUNT environment variable (#1117, see environment variable docs).
• Add GRAPH_NODE_ID environment variable as an alternative to --node-id (#1136, see environment variable docs).
• Fix block/call handlers from dynamic data sources not being loaded on node restart (#1087).
• Fix ingesting blocks with no transactions (#1099).
• Fix indexing the genesis block with Ganache (#1094).
• Fix skipping call traces without insufficient data (#1104).
• Fix Postgres indexes for string fields to support values of arbitrary length (#1138).
• Update codebase to Rust 1.37 (#1118).
• Update dependencies.

v0.14.0

v0.14.0

v0.13.2

v0.13.2

v0.13.1

v0.13.1

v0.13.0

v0.13.0

v0.12.0

Changes

• Add a log.log host export for the new graph-ts logging API (see the AssemblyScript API documentation for more information) (#599, #943).
• Measure the effect of tokio and database contention in subgraph indexing (#917, #918, #921, #926).
• Document the templates field in the manifest spec (#910, contribution by @dOrgJelli).
• Don't block chain head updates when there is back-pressure from block streams (#929).
• Write block ingestion and GraphQL query activity to Elasticsearch (#928).
• Add a database index for event sources in the event_meta_data (#945).
• Add database indexes for reference fields (#916, #944).
• Allow trace logging in production builds (#948).
• Bump tokio from 0.1.15 to 0.1.20 (#946).
• Increase thread pool size to 100 (#946).
• Make block stream errors non-fatal to allow to retry fetching blocks (#947).

v0.11.0

Block, transaction and call handlers

Until now, the only triggers for indexing were events. This release adds support for triggering based on blocks and transactions/calls in the form of blockHandlers and callHandlers (in addition to the existing eventHandlers).

From the documentation:

While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an EthereumCall as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.

Regarding block handlers:

In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a predefined filter.

For more information about how to define and write call and block handlers, please refer to the documentation.

Note: This feature requires Parity archive nodes with the trace API enabled.

Adaptive block range scanning

In order to deal with Infura's limit of returning a maximum of 1000 matches for eth_getLogs, the block range based scanning for events is now adapting the size of the block ranges being scanned when necessary. After a problematic block range has been processed, the block range size returns to the original ETHEREUM_BLOCK_RANGE_SIZE value.

Efficient entityCount querying

Until now, querying the entityCount of a subgraph deployment via the subgraph of subgraphs at /subgraphs lazily counted the entities of the deployment. This becomes increasingly expensive as subgraphs grow in size.

Starting with this release, the entityCount is stored in the deployment and is updated whenever changes are made to the entities of the subgraph, including when operations are being reverted due to a block reorg. This makes querying entityCount efficient.

Other changes

• Use a global database lock to prevent Graph Nodes from running migrations in parallel (#922).
• Capture and log potential thread and database contentions (#917, #918, #921).
• Revert dynamically created data sources that are affected by block reorgs (#890, #907).
• Add log message codes to subgraph and query logs for analytics (#915).
• Hide URL passwords from logs (#849, #853).
• Remove subgraph_list JSON-RPC method (#899).

v0.10.0

Data source templates / dynamic data sources

Also referred to as dynamic contract subscriptions, as this is currently the main use case.

This feature supports creating new data sources from templates while indexing the subgraph. The motivation behind this is to provide a natural way of indexing registry/factory contracts that reference many other (sub)contracts.

See Define a Subgraph: Dynamic Data Sources in the docs for more details.

Details about the implementation are described in the pull request that introduced the feature:

When starting a subgraph, the node now not only loads the manifest, it also loads the dynamic data sources from the store and fetches their files from IPFS. It then injects the data source instances into the subgraph instance before starting the indexing.

Whenever we we process a block and mappings request new data sources, these data sources are collected and, after having processed the block, are instantiated from templates. We then process the current block again but only with those new data sources. The entity operations from this are merged into the ones we already have for the block. After that, the dynamic data sources are persisted by adding the data sources to the subgraph instance and by adding entity operations to store them in the db (for 1.).

If new data sources have been added in a block, the block stream is restarted to incorporate events that are relevant for the new data sources going forward. We figured this would be easier to do (and it is) than modifying the block stream while it is already running.

Anonymous events

Anonymous Solidity events are used by projects like Maker. Supporting them requires filtering events not by their usual signature (e.g. Transfer(address,address)) but by their topic 0 value.

This version adds support for that by allowing event handlers to specify the topic0 value to filter by. For more information see Define a Subgraph: Anonymous Events in the docs.

Full support for GraphQL fragments

This releases finishes the support for GraphQL fragments both inline and spread in.

Query complexity limiting

Graph Node now supports limiting complexity of queries both in terms of potential number of entities returned and query depth, similar to how GitHub do it in their GraphQL API.

The following environment variables can be used for this:

• GRAPH_GRAPHQL_MAX_COMPLEXITY — limits the complexity of queries (default: unlimited).
• GRAPH_GRAPHQL_MAX_DEPTH — limits the depth of queries (default and maximum: 255).

Entity table splitting

Starting with this release, Graph Node stores entities and their history in a Postgres schema dedicated to the subgraph deployment. Every subgraph deployment now gets their own entities table, which speeds up queries significantly. Existing entity data in the global entities table can still be queried as before.

Other changes

• Fix list equality filters.
• Log smart contract call times.
• Reduce subgraph logging overall to reduce noise around event processing.
• Switch to the latest IPFS client version for HTTPS support.
• Add environment variables to control the block range size used while scanning the history of the chain (ETHEREUM_PARALLEL_BLOCK_RANGES) as well as the number of parallel block ranges to scan (ETHEREUM_BLOCK_RANGE_SIZE).

v0.9.0

Ethereum tuples / Solidity structs

This release adds support for Ethereum tuples (structs in Solidity). Events with tuple parameters are now decoded correctly and passed to mappings as EthereumTuple objects. Passing tuples as arguments to smart contract calls is support as well.

Other changes

• The GraphQL execution has been simplified in preparation of performance improvements.

v0.6.0

Subgraph versions & metadata

Subgraphs are now deployed in two steps: first, the subgraph name is created with e.g. graph create (using the Graph CLI), then a subgraph version is deployed to this name with graph deploy.

Subgraph versions

Subgraphs are now versioned. When a new version is deployed, it replaces the previous version. Accessing a subgraph by name (e.g. via /subgraphs/name/my/subgraph) always queries the current version. Previous versions can still be queried by ID (/subgraphs/id/Qm....).

The built-in subgraph of subgraphs (see below) allows to query meta data about the current as well as previous versions.

Subgraph metadata

This adds endpoints for querying subgraph meta data (/subgraphs and /subgraphs/graphql) over HTTP and WebSockets. For any subgraph created, the versions that have been deployed can be queried along with their manifest information, deployment status, entity count and more.

Ethereum improvements

• Overloaded events are now supported in graph-node.
• Indexed event parameters are now properly represented as Bytes with a length of 32.
• Event parameters that are encoded as a byte array with a length that is not a multiple of 32 are now supported properly.

Big decimal support

Large decimal numbers are now supported via the BigDecimal type in the subgraph schema and in AssemblyScript mappings. Conversions from BigInt and string to BigDecimal are implemented as well as basic BigDecimal arithmetics and a new bigInt.divDecimal(...) devision method for BigInts to obtain decimal numbers.

IPFS file streaming

A new ipfs.map(hash: string, callback: string, userData: Value, params: string[]): void host export has been added, allowing to stream files from IPFS and having a callback in the mapping called for every value, along with the provided user data). This is particularly useful for streaming JSONLines files.

GraphQL API changes

Interfaces

Support for interfaces has been added to the GraphQL API. Subgraphs can now define interfaces in their schema and instantiate entities that implement these interfaces. The only restriction currently is that entities that implement the same interface must have distinct IDs.

Arguments for relationship fields

One-to-many and many-to-many relationship fields can now be queried with arguments. The same filtering and ordering API is used as for top-level query fields.

Limit results to 100 entities per collection

The results returned for any collection in a GraphQL result are now limited to 100 entities per collection. This number can be further reduced by providing a first argument to the collection query field.

Subscription throttling

• Subscriptions will fire at most every 500ms while a subgraph version is still syncing.
• The built-in "subgraph of subgraphs" is always throttled like that.

Other GraphQL changes

• @derivedFrom is now supported for one-to-one relationships.
• GraphQL queries can optionally be limited with a timeout. This can be set via the GRAPH_GRAPHQL_QUERY_TIMEOUT environment variable.
• Return a 200 even if there were GraphQL errors. Required for GraphQL clients.
• Handle @include directive in queries correctly.
• Parse query variables correctly.
• Add GraphQL filter fields for list values.

Mapping changes

• The GRAPH_EVENT_HANDLER_TIMEOUT environment variable now allows to set a timeout after which event handlers will be terminated and considered failed.
• Add a typeConversion.bytesToBase58 host export for mappings.
• Fix passing BigInt values starting with 0x80 to mappings.
• Add input: Bytes member to Ethereum transactions (only if the mapping's apiVersion is > 0.0.1.

Store changes

• Use Postgres indexes for entities and their attributes to speed up queries.
• Use a Postgres connection pool for the store.
• Don't record entity history that we don't need, reducing the size of the database significantly.

Other changes

• Switch to Rust 2018.
• Log query execution with timing data.
• Handle panics in graph-node better and shutdown the node when it makes sense.
• Add health-check endpoint by making GET / return a 200 status.
• All environment variables supported are now documented.
• The fast Ethereum block scan that was previously hard-coded to the first 4,000,000 blocks can now be adjusted with the ETHEREUM_FAST_SCAN_END environment variable.
• Block ingestion can now be disabled with the DISABLE_BLOCK_INGESTOR environment variable.
• The IPFS file size for ipfs.cat can be limited with the GRAPH_MAX_IPFS_FILE_BYTES environment variable.
• The timeout for IPFS file resolution now defaults to 30s and can be controlled with the GRAPH_IPFS_TIMEOUT environment variable.
• Log IPFS file resolution errors.