v0.17.1

• Reject time-travel queries with block numbers that are in the future (#1437).
• Fix setting fields to null being ignored in certain cases (#1428).
• Fix error in GraphQL execution caused by overly aggressive assertion in prefetch (#1422).
• Log GraphQL query variables (#1429).
• Dependency updates: serde.

v0.17.0

GraphQL query prefetching (#1386)

Previously referred to SQL query combination, this feature speeds up nested queries by a factor of about 10x by batching every GraphQL query level into a single Postgres SQL query. A query like

{
  bands(first: 100) {
    name
    musicians(first: 100) {
      name
    }
}

previously would result in one SQL query for the bands and 100 SQL queries for the musicians of each individual band. With query prefetching, only two SQL queries are executed: one for the bands and one for the musicians of all bands.

This is now enabled by default.

Time-travel queries (#1397)

It is now possible to run queries against the state of a subgraph at an arbitrary block height, and not just the latest block. So far, a query like transactions { id } would always return the data for the latest set of transactions, and rerunning it might return a different result if the subgraph had ingested more transactions in the mean time.

It is now possible to fix the block at which to query by passing an additional block argument to top-level fields:

{
  transactions(block: { number: 7000 }) {
    id
  }
}

will return the transactions as of the block with that number, and

{
  transactions(block: { hash: "0xdeadbeef" }) {
    id
  }
}

will return transactions as of that block hash. To make absolutely sure the query result is reproducible, the form with the hash should be used as which block is designated by number may change if the chain is reorganized (though using number far enough away from the chain head will be fine).

If a query does not explicitly specify a block, we continue to run it against the latest available data, so that the behavior for existing queries does not change.

Indexing performance

Work on improving the indexing performance continues in this release. The following changes have been implemented since v0.16.1.

• Add indexing metrics using Prometheus (#1338, #1360, #1361, #1362, #1374).
• Optimize store.set entity validation (#1384).
• Batch-load entities before applying changes (#1388).

Other changes

GraphQL

• Catch unknown fields in GraphQL queries (#1339).
• Log query execution time (#1402).
• Add query execution time metrics using Prometheus (#1403).

Ethereum

• Dynamically adjust block range sizes when scanning for triggers to send Ethereum nodes manageable requests (#1370).
• Fix reorg handling on short chains (#1377).
• Fix call handlers not being trigger in dynamic data sources (#1382).
• Limit JSON-RPC retries to avoid getting stuck on reorg'ed blocks (#1396).
• Ensure Ethereum triggers (blocks, calls, events) are always processed in the correct order (#1413).
• Add block ingestor metrics using Prometheus (#1401, #1403).

Mappings

• Reduce frequency of handler timeout checks to speed up indexing (#1353).
• Log Ethereum transaction hash when a handler fails (#1371).

Store

• Exit with error when losing the connection to Postgres (#1348). This allows to environments like Kubernetes to restart the nodes and therefore recover from lost Postgres connections.
• Allow unneeded old blocks to be deleted from the store periodically (#1408).

Misc

• Add missing ports to docker-compose.yml (#1385, thanks @Amxx!).
• Make startup asynchronous to avoid getting stuck connecting to Ethereum nodes (#1352, #1372).
• Detect invalid ETHEREUM_REORG_THRESHOLD values (#1366).
• Rename graph-datasource-ethereum crate to graph-chain-ethereum (#1368).
• Document call and block handlers in the manifest spec.
• Dependency updates: chrono, derive_more, git-testament, jsonrpc-http-server, num-traits, reqwest, serde_derive, serde_json, slog-term, uuid.

v0.16.1

• Use retrying IPFS resolver to load subgraph files (#1239).
• Fix parsing GraphQL block hashes and numbers (#1335).
• Allow to recover from database connection errors (#1348).
• Dependency updates: reqwest.

v0.16.0

Relational database schemas (#1020 via #1159)

Subgraph data is now stored in Postgres using relational schemas. Instead of a storing all entities of a subgraph in a single table using JSONB, each entity type gets a dedicated table, with each field being stored in its own column.

This has several advantages:

1. Reading and writing are faster, more scalable.
2. Entity data can be validated and enforced better, preventing bugs in subgraphs.
3. Introspecting the data is much easier when debugging.

The stricter validation of entities written to the store may cause subgraphs that work today to fail when being deployed. A note from @lutter, who implemented this feature:

As part of the switch to the relational storage scheme, subgraph entities are validated more strictly than they were in the past. In particular, the store will reject attempts to store entities that have null in fields that are marked as non-null in the GraphQL schema. If your subgraph reports such errors after you deploy a new version, you can address that either by marking the field as nullable in the GraphQL schema by leaving the ! off its type, or by changing your mappings to ensure that the field is always set to a non-null value.

Note: This only affects new subgraph deployments. Existing deployments will keep using the JSONB schema. On the hosted service we will slowly clean up unused deployments over time until we can drop the old JSONB-based schema entirely.

Start block for data sources (#1262, #1294, #1320)

Until now, subgraphs were always indexing from the genesis block. This involved scanning the entire chain for relevant blocks, logs and traces, even if the subgraph contracts were only deployed recently.

This was fine initially. However, with more expensive features—such as block and call handlers—being added and more advanced subgraphs being developed, it has often become desirable to skip irrelevant old blocks entirely to speed up indexing.

This is now possible. As of this release, data sources can specify an optional startBlock number in the manifest:

dataSources:
  - name: Gravity
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      abi: Gravity
      startBlock: 6000000

The subgraph will then start indexing from this block. If there are multiple data sources with or without start blocks, the earliest of these blocks is used as the starting point. The absence of a startBlock is equivalent to 0 (aka the genesis block).

Other changes

GraphQL

• Fix querying interfaces by id (#1204)
• Fix following interface references (#1303 via #1307)
• Support where filter on relationship fields (#1212)
• Validate @derivedFrom directives on subgraph schemas (#1247)

Ethereum

• Add an Ethereum contract call cache to speed up indexing (#1230 via #1270)
• Detect failed Solidity assertions in try_ calls (#1162)
• Detect Bad instruction fd errors in try_ calls (#1327)
• Allow recursive data source template creation within the same block (#1185)
• Handle Alchemy timeouts in eth_getLogs gracefully (#1242)
• Make eth_getLogs scanning more efficient (#1260)
• Only fetch transaction receipts when necessary (#1308, #1326)

Mappings

• Reduce memory usage and number of threads by using one thread per mapping instead of one per data source (#1281)

Database

• Allow subgraphs to make progress while Postgres is autovacuuming the subgraphs table (#1175)
• Use a single connection pool per node (#1232)
• Preload pg_stat_statements in Docker Compose setup (#1163)
• Fix default Postgres port in the README (#1181, thanks @akeem!)

Monitoring

• Add Prometheus instrumentation support (#1259 via #1264)

Configuration

• Add new GRAPH_IPFS_SUBGRAPH_LOADING_TIMEOUT environment variable for loading subgraph manifests from IPFS (#1091, #1238, #1244)
• Add optional limit for GraphQL/WS operations using the GRAPH_GRAPHQL_MAX_OPERATIONS_PER_CONNECTION environment variable (#1160)

Misc

• Don't skip the genesis block when indexing (#1295 via #1297)
• Allow Docker image to wait for other services using full URLs (#1275)
• Fix Docker builds by passing --locked to Cargo
• Support multiple Ethereum networks in Docker image by sperating networks in the ethereum environment variable with spaces (#1332)
• Fix yarn commands in README (#1282, thanks @ana0!)
• Update dependencies (bs58, chrono, clap, crossbeam-channel, graphql-parser, hex, hex-literal, hyper, indexmap, jsonrpc-core, jsonrpc-http-server, lru_time_cache, num-bigint, serde, serde_derive, serde_yaml)
• Remove dependencies on itertools and sentry

v0.15.1

• Fix WASM memory allocation bug (#1154).
• Fix incorrect contract call reversion detection caused by ambiguity between Ganache and Parity (#1155).

Note: Make sure to also read the release notes for v0.15.0.

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