Skip to content

v1.0.1 - scaffold a nest from a subgraph

Choose a tag to compare

@github-actions github-actions released this 03 Aug 08:53
· 878 commits to main since this release
4c607b2

Scaffold a nest from a subgraph manifest. In-place safe from 1.0.0: no data migration, no config changes.

nuthatch init --from-subgraph QmVPhLwuv9zn2c761Ua7eJAFXBmrNsW32XUYsj1GKtNX4X

Our first external contribution, from @PaulieB14 — thank you.

What it does

Maps dataSources[[contracts]] and templates[[templates]], vendors every ABI from the CID the manifest pins, carries startBlock across, and carries each dataSource's eventHandlers over as that contract's event allowlist — so a subgraph that handled only Transfer does not silently grow a table for every other event the ABI declares.

The pinned ABIs are the point. For a proxy-heavy codebase, Sourcify returns the proxy ABI, which declares none of the events the contract actually emits. A manifest pins the ABI the subgraph was built against, which is the one you want.

Factory rules are inferred only where a parameter unambiguously names a template. Which template a factory creates lives in the mapping WASM, not the manifest, so anything ambiguous is reported by name with its candidates for you to resolve — never guessed. A wrong guess would be a nest that silently indexes the wrong children, which is worse than a nest that tells you what it could not work out.

Against the POA stack from #241 — 5 contracts, 19 templates, 235 tables — it inferred 4 factory rules and listed the rest with candidates.

A fix that came with the review

The contribution as submitted let a manifest choose what your machine fetches. link_cid returned whatever string the manifest's mapping.abis[].file./ held, and the URL builder passed any http(s):// string through verbatim, so a manifest carrying

file:
  /: "http://169.254.169.254/latest/meta-data/iam/security-credentials/"

would make init --from-subgraph issue that request from the operator's machine and write the reply into abis/. On a cloud host, that address serves instance credentials.

The missing distinction was who supplied the reference. The --from-subgraph argument is the operator's and may still be any URL — that is intent. Everything inside the manifest arrives from a public gateway and is untrusted input that happens to be handed to an HTTP client. That is now an explicit Origin at the single choke point, visible at both call sites rather than implied.

Two smaller hardenings came with it:

  • CIDs must be CID-shaped. They are concatenated onto a gateway prefix, so ../, a query string or a fragment could reach outside the path the gateway meant to serve. The previous check caught / and space but not ?, #, or percent-encoding.
  • Response bodies are capped at 16 MiB and streamed rather than buffered. A gateway is a third party, and the reply size was its decision rather than ours.

Both are mutation-tested: each control was reverted and the corresponding test confirmed to fail.

No released version is affected — this shipped fixed, in the same release that introduced the feature.

Verifying the download

curl -fsSLO https://github.com/nightswatchhq/nuthatch/releases/download/v1.0.1/nuthatch-x86_64-unknown-linux-gnu.tar.gz
curl -fsSLO https://github.com/nightswatchhq/nuthatch/releases/download/v1.0.1/nuthatch-x86_64-unknown-linux-gnu.tar.gz.sha256
sha256sum -c nuthatch-x86_64-unknown-linux-gnu.tar.gz.sha256
Artifact Contains
nuthatch-x86_64-unknown-linux-gnu.tar.gz · :1.0.1 · :latest embedded — no database driver
nuthatch-scaled-x86_64-unknown-linux-gnu.tar.gz · :1.0.1-scaled scaledworker, control, serve --hot-store

be your own indexer.