hashgraph / hashgraph/hedera-the-graph
Make IPFS in graph-node compatible with IPFS Gateway API
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
The IPFS endpoints provided by TheGraph, `https://ipfs.network.thegraph.com/` and `https://api.thegraph.com/ipfs/`, were having intermittent issues lately, returning either `403` or `404`. See https://status.thegraph.com/incidents/yl8bzfy6g6gw for example.
This triggers the following error in the graph-node `v0.35.1` (here using a public IPFS Gateway API `https://ipfs.io/`, see below)
```
Jun 10 23:56:15.341 ERRO Is there an IPFS node running at "https://ipfs.io/"?
thread 'tokio-runtime-worker' panicked at node/src/chain.rs:90:25:
Failed to connect to IPFS: HTTP status client error (410 Gone) for url (https://ipfs.io/api/v0/version)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Panic in tokio task, aborting!
```
This is because up until `v0.35.1`, graph-node only supported the IPFS RPC API. However, this API is not well-adopted and it's hard to find replacements in case the aforementioned endpoints provided by TheGraph are out of service.
However, starting from [`v0.36.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.36.0), graph-node supports both IPFS Gateway and RPC APIs (see https://github.com/graphprotocol/graph-node/pull/5600). The IPFS Gateway API has more support within the ecosystem, and it is easier to find a 3rd party service that provides it. Indeed, IPFS itself provides a Public Gateway API at [`https://ipfs.io/`](https://about.ipfs.io/). Moreover, here is a list public gateways https://ipfs.github.io/public-gateway-checker/ that we may use (although we should not use any of those that has not been previously vetted by security).
Therefore, updating to `v0.36.0` or higher would allow us to use more IPFS providers, which in turn makes our service more robust. For example, using graph-node `v0.36.1` with IPFS `https://ipfs.io/`, we can see in the logs how it detects it is an IPFS Gateway API
```
INFO Connecting to IPFS server at 'https://ipfs.io/'
TRCE Run with retry: IPFS.Gateway.send_test_request
TRCE Run with retry: IPFS.RPC.send_test_request
INFO Successfully connected to IPFS gateway at: 'https://ipfs.io/'
```
> [!CAUTION]
> In case of a future update of graph-node, **DO NOT USE** [`v0.38.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.38.0) release. It contains a regression that causes subgraph failures. It was fixed in [`v0.39.1`](https://github.com/graphprotocol/graph-node/releases/tag/v0.39.1).
For context, the IPFS RPC API is the Kubo RPC API https://docs.ipfs.tech/reference/kubo/rpc/#getting-started.
This is what we use in our umbrella chart https://github.com/truecharts/public/blob/d0fb2efb345284495fa274a2da8b64ac69d6c827/charts/stable/ipfs/values.yaml#L2.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the graph-node version and IPFS configuration in this repository, then compare them with the v0.36.0, v0.38.0, and v0.39.1 release notes linked in the issue. Update the deployment configuration to a supported version that provides Gateway API compatibility, avoiding v0.38.0, and verify that the resulting configuration uses the intended IPFS endpoint.
Written by the indexing model from the issue text.
Assessment
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100