10

I followed this tutorial on the graph document: https://thegraph.com/docs/quick-start#local-development

However, I got an error message after I run yarn deploy-local.

Failed to deploy to Graph node http://127.0.0.1:8020/: Ethereum network not supported by registrar: mainnet

Is there anything I am missing here?

This is the whole log

Skip migration: Bump mapping apiVersion from 0.0.1 to 0.0.2
  Skip migration: Bump mapping apiVersion from 0.0.2 to 0.0.3
  Skip migration: Bump mapping apiVersion from 0.0.3 to 0.0.4
  Skip migration: Bump mapping specVersion from 0.0.1 to 0.0.2
✔ Apply migrations
⚠ Warnings loading subgraph from subgraph.yaml: Warnings in subgraph.yaml:
  
    Path: repository
    The repository is still set to https://github.com/graphprotocol/example-subgraph.
    Please replace it with a link to your subgraph source code.
  
    Path: description
    The description is still the one from the example subgraph.
    Please update it to tell users more about your subgraph.

✔ Load subgraph from subgraph.yaml
  Compile data source: Gravity => build/Gravity/Gravity.wasm
✔ Compile subgraph
  Copy schema file build/schema.graphql
  Write subgraph file build/Gravity/abis/Gravity.json
  Write subgraph manifest build/subgraph.yaml
✔ Write compiled subgraph to build/
  Add file to IPFS build/schema.graphql
                .. QmbSFRGGvHM7Cn8YSjDL41diDMxN4LQUDEMqaa5VVc5sC4
  Add file to IPFS build/Gravity/abis/Gravity.json
                .. QmajZTadknSpgsCWRz9fG6bXFHdpVXPMWpx9yMipz3VtMQ
  Add file to IPFS build/Gravity/Gravity.wasm
                .. QmbK8bwncci52cstF3P8Q8i4oGjrMt1pUqdv5Uf1VXqXdb
✔ Upload subgraph to IPFS

Build completed: QmYc13fDLwyvTT5crdGWGuFbaN23YxJ8RG8EGNW4Bac24j

✖ Failed to deploy to Graph node http://127.0.0.1:8020/: Ethereum network not supported by registrar: mainnet
error Command failed with exit code 1.

UPDATE: Here is my subgraph.yaml

specVersion: 0.0.2
description: Gravatar for Ethereum
repository: https://github.com/graphprotocol/example-subgraph
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      abi: Gravity
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.4
      language: wasm/assemblyscript
      entities:
        - Gravatar
      abis:
        - name: Gravity
          file: ./abis/Gravity.json
      eventHandlers:
        - event: NewGravatar(uint256,address,string,string)
          handler: handleNewGravatar
        - event: UpdatedGravatar(uint256,address,string,string)
          handler: handleUpdatedGravatar
      file: ./src/mapping.ts
3
  • Did you ever get this resolved? I'm having the same problem. Jul 14, 2021 at 19:26
  • Unfortunately no...
    – user76333
    Jul 15, 2021 at 9:19
  • For me this was a configuration issue. The local blockchain node wasn't accessible because firewall settings blocked incoming connections. This blocked access to the node from Docker even though both were running locally. Jul 19, 2021 at 17:48

7 Answers 7

3

That error message “Ethereum network not supported by registrar: mainnet” can be misleading, at least it was in my case. I was getting this error because I had run hardhat node on the host, but not with --hostname 0.0.0.0, and I presume that the same would apply for ganache-cli.

Since the graph-node Docker container is configured to look for an Ethereum network named mainnet at the host’s IP address on the Docker internal network, it couldn’t see the hardhat node that was listening on 127.0.0.1. So really the error wasn’t that “mainnet” wasn’t supported, but that the IP address configured for “mainnet” could not be reached. Running hardhat node --hostname 0.0.0.0 did the trick.

2

I got the same issue with graph-node and Ganache (port: 7545) on my Mac.

Update <graph-node>/docker/docker-compose.yml graph-node's ethereum environment works for me

enter image description here

services:
  graph-node:
    image: graphprotocol/graph-node
    ports:
      - '8000:8000'
      - '8001:8001'
      - '8020:8020'
      - '8030:8030'
      - '8040:8040'
    depends_on:
      - ipfs
      - postgres
    environment:
      postgres_host: postgres
      postgres_user: graph-node
      postgres_pass: let-me-in
      postgres_db: graph-node
      ipfs: 'ipfs:5001'
      ethereum: 'mainnet:http://host.docker.internal:7545'
      GRAPH_LOG: info
1

While running a graph node locally, in subgraph.yaml, the network value should be mainnet, this is not clear in the documentation.

From this awesome dapp-development-with-a-local-subgraph article,

The network for all of your contracts defined in your subgraph.yml file must be mainnet even though you are deploying to a local node. This will not interact with the main Ethereum network — it’s just the way that subgraph.yml needs to be configured for your local node. I learnt the hard way…

3
  • Thank you for your reply. Unfortunately, my network value on subgraph.yaml is set to mainnet and still having the same issue
    – user76333
    May 27, 2021 at 1:08
  • @hphex can you include subgraph.yaml with your question?
    – hack3r-0m
    May 27, 2021 at 2:31
  • I've updated the question above with my default subgraph.yaml.
    – user76333
    May 31, 2021 at 0:17
1

Getting the same issue but with the Mumbai network, solved by changing the RPC link to point to the Mumbai network.

Changing this line: https://github.com/graphprotocol/graph-node/blob/e1980d73b7ed885b55d9ae8a5e46b7f991a33abc/docker/docker-compose.yml#L20 to mumbai:https://rpc-mumbai.maticvigil.com

0

This solution fixed the issue for me:

  1. Run etherium node like this: hardhat node --hostname 0.0.0.0 or ganache-cli -h 0.0.0.0

  2. Change ethereum: 'mainnet:http://host.docker.internal:8545' to ethereum: 'mainnet:0.0.0.0:8545' in docker-compose.yml

0

In my case I was trying to setup the Subgraph Debug Forking for Arbitrum and ended up having the same issue that got fixed by using:

 network: arbitrum

instead of:

 network: arbitrum-one

in subgraph.yaml. Not sure why as the second one is the correct value (might have to do with the fact this forking functionality is developed by a contractor company).

0

This error can also show if you already have an existing docker container running that is connected to this network. so ensure those are stopped before running the new container.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.