Pagination- Error: Call retries were exceeded

🆘 Support
1

Hi, I am using NextJS on the frontend and I was generating static paths like this:

export async function getStaticPaths() {
  const data = await request({
    query: gql`
      query {
        allKnowledgePages(first: 100) {
          slug
        }
      }
    `,
  });

  const paths = data.allKnowledgePages.map((knowledgePage) => ({
    params: {
      knowledgePageSlug: knowledgePage.slug,
    },
  }));

  return { paths, fallback: false };
}

It was working great. But now, our records has exceeded limit: 100.

And now I’m trying to generate paths using the pagination. This is how I’m doing the pagination:

export async function getStaticPaths() {
  let skip = 0;

  const limit = 100;

  let keepQuerying = true;

  let allKnowledgePages = [];

  while (keepQuerying) {
    const data = await request({
      query: gql`
        query  {
          allKnowledgePages(first: ${limit}, skip: ${skip}) {
            slug
          }
        }
      `,
    });

    allKnowledgePages = allKnowledgePages.concat(
      data.allKnowledgePages
    );

    skip += limit;

    if (data.allKnowledgePages.length < limit) {
      keepQuerying = false;
    }
  }

  const paths = allKnowledgePages.map((knowledgePage) => ({
    params: {
      knowledgePageSlug: knowledgePage.slug,
    },
  }));

  return { paths, fallback: false };
}

I have confirmed that pagination is working and the allKnowledgePages have 100+ records.

But the problem is I’m getting this error:

Error: Call retries were exceeded
    at ChildProcessWorker.initialize (/project/node_modules/next/dist/compiled/jest-worker/index.js:1:11661)
    at ChildProcessWorker._onExit (/project/node_modules/next/dist/compiled/jest-worker/index.js:1:12599)
    at ChildProcess.emit (node:events:520:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12) {
  type: 'WorkerError'
}
2

Further information:

The error is occurring only in the devlopment.

Production is working fine and generating all pages.

Also, the Preview is also working as expected.

3

Further investigating, I found that this is only happening when there are 100+ records in the allKnowledgePages array.

I thought that might be this issue is because of multiple API calls.

So, I changed the const limit = 100 to const limit = 20.

It works great if I break the loop at skip > 99.

if (skip > 99) {
      keepQuerying = false;
    }

But if I don’t break it, then it will cause the same error.

4

@itsahmedkamal, can I ask what version of Next.js you’re using, what version of Node.js it’s on, and what kind of hardware you’re running it on in development?

I’m trying to see if it’s another variant of a Next.js bug or if it’s a new problem altogether.

5

NextJS version: 13.3.0
NodeJS version: 16.14.0
Hardware: Macbook Pro (M2 Pro, 16GB)

I saw the NextJS bug link you mentioned and it looks like that v13.3.0 is causing problem.

But, still, I would want to know why it works in Preview & Production and not in development?

6

Thank you for the details! Please give us a bit of time to investigate. We need to try to reproduce and debug it locally.

7

Sure - no problem - take your time!

8

@itsahmedkamal I’m so sorry for the slow reply here! I was out of the office last week and the handoff didn’t work right. I apologize.

The good news is that I’ve since made a Next 13.3.0 repo and managed to reproduce your issue. Fortunately, upgrading to 13.3.4 seems to fix the issue with no code changes.

Could you please try that? It should hopefully be as simple as changing your Next dependency in package.json to: "next": "13.3.4" and running npm install again. Please let me know if that helps at all.

If that fixed it, you may also wish to consider using SemVer indicators in your package.json, like "^13.3.4" (for minor versions) or "~13.3.4" (for patch versions) so that your packages can auto-upgrade across versions that only have bugfixes or backward-compatible new features.

If upgrading to 13.3.4 did not fix your issue, could you please provide a sample repo (a MVP is fine, with just the files demonstrating the problem, and any private secrets, etc. stripped out)? If you don’t want to make it public, you can email us the details at support@datocms.com (and CC me at r.tuan@datocms.com if you’d like).

Sorry again for the slow reply!

1 Like
9

@roger No problem for the delay.

And I’m glad to tell you the solution you suggested is working perfectly.

Thank you so much!!!

2 Likes
10

Great, happy that helped!

1 Like