Website | Docs | Discord

XXXXX Subgraph migration

This quest is to migrate the XXXXX subgraph to Squid SDK. The resulting squid should match the GraphQL API of the subgraph as close as possible, by migrating schema.graphql. The judges reserve the right to request improvements afther the initial review of the submission. Reach out to the Discord Channel for any tech questions regarding this quest. You can use the template squid as a starter.

Quest Info

Category	Skill Level	Time required (hours)	Max Participants	Reward	Status
Squid Deployment	$\textcolor{orange}{\textsf{Medium}}$	~60	5	$\textcolor{red}{\textsf{3000tSQD}}$	open

Acceptance criteria

General

Ultimately, the solutions are accepted at the discretion of judges following a manual review. This sections is a rough guide that is in no way binding on our side.

Some of the reasons why the solution will not be accepted include:

• The submission is an unmodified squid template. We will not reward these by chance. Give up.
• We receive two or more solutions with identical or almost identical code. If we detect that, either one or none of the affected submissions will be rewarded, depending on your luck.
• The squid does not start.
• The squid fails to sync fully due to internal errors.
• The squid fails to sync fully in a reasonable time due to severe performance issues. Follow the best practices guide to avoid these.
• The squid writes no data into its database.
• Data returned for any query is not consistent with subgraph data. You may find this tool useful for comparing squid and subgraph APIs.

It is desirable that your solution:

• includes a suite of test GraphQL queries that touches every schema entity and, if used, every custom resolver at least once, with corresponding subgraph queries (listing in README is enough)
• has high code quality (readability, simplicity, comments where necessary)
• avoids any "sleeping bugs": logic errors that accidentally happen to not break the data
• follows the standard squid startup procedure:

  git clone <repo_url>
  cd <repo_url>
  npm ci
  sqd up
  sqd process &
  sqd serve
  

  If it does not, describe your startup procedure in the README.

Please test your solutions before submitting. We do allow some corrections, but judges' time is not limitless.

To submit, invite the following github accounts to your private repo : @dariaag, @belopash, @abernatskiy and @dzhelezov.

Permissible deviations from the subgraph schema

• You can use String in place of Bytes in your submissions
• The only way to handle many-to-many relations in squids is by adding explicit join tables. Addition of such tables is an expected change when schemas with such relations are migrated.

Rewards

tSQD rewards will be delivered via the quests page of Subsquid Cloud. Make sure you use the same GitHub handle to make a submission and when linking to that page.

Winners will be listed at the quest repository README. If you do not wish to be listed please tell us that in an issue in your submission repo.

Useful links

• Squid development master guide
• TheGraph migration guide
• Subsquid Cloud best practices guide (includes a lot of good non-Cloud related advice)
• compareGraphQL tool

Setup and common errors

1. Install Node v16.x or newer https://nodejs.org/en/download

2. Install Docker https://docs.docker.com/engine/install/

3. Install git https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

4. Install Squid CLI

   npm i -g @subsquid/cli@latest

How to run a squid

Full startup procedure for newly developed squids:

1. Install dependecies:

npm ci

2. Generate model

sqd codegen

3. Generate types

sqd typegen

4. Build the squid

sqd build

5. Open docker and run:

sqd up

6. Generate migrations:

sqd migration:generate

7. Start processing:

sqd process

8. Start a local GraphQL server in a separate terminal:

sqd serve

Types (./src/abi), models (./src/model) and migrations (./db) are typically kept within squid repos after they become stable. Then the startup procedure simplifies to

npm ci
sqd up
sqd process &
sqd serve

Possible errors

1. Docker not installed

X db Error × query-gateway Error
Error response from daemon: Get "https://registry-1.docker.jo/v2/": uri ting to 127.0.0.1:8888: dial cp 127.0.0.1:8888: connectex: No connection

2. Git not installed

Error: Error: spawn git ENOENT
at ChildProcess._handle.onexit (node: internal/child_process: 284:19)
at onErrorNT (node: internal/child_process:477:16)
at process.processTicksAndRejections (node: internal/process/task_queues:82:21)

3. Dependencies not installed. Run npm ci

sqd typegen
TYPEGEN
    Error: spawn squid-evm-typegen ENOENT
    Code: ENOENT

4. Rate-limiting. Get a private RPC endpoint from any node provider, then change the rpcUrl in processor.ts

will pause new requests for 20000ms {"rpcUrl":"https://rpc.ankr.com/eth",
"reason" : "HttpError: got 429 from https://rpc.ankr.com/eth"}

If necessary, rate limit your RPC queries.

Best practices extras

1. Batch saving

let transfers: Transfers[] = [];
...
ctx.store.save(transfers);

2. Using map instead of array to avoid duplicate values

let transfers: Map<string, Transfer> = new Map();
...
ctx.store.upsert([...transfers.values()]);

3. Verify both log addresses and topics before processing events.

 if (log.topics[0] === erc721.events.Transfer.topic && log.address === CONTRACT_ADDRESS) {
...
}