gatsby: Jest fails with `Couldn't find temp query result` error

I’ve had some success setting GATSBY_CPU_COUNT=2.

I guess that it limits how much stuff Gatsby tries to do at once, limiting memory consumption.

Also, if you are on CI and have a limited number of cores, it leaves free cores for other processes, like Cypress, local servers, etc.

Minimal reproduction example is a pipe dream when a problem is related to concurrency and manifests itself only in non-toy projects.

I wouldn’t consider it resolved. My use case doesn’t involve executing createPage in onCreateWebpackConfig.

I had this issue too with v4.12.1. For me, the solution was to run gastby clean. After that, build ran correctly.

Hope it helps someone.

We’re facing the same issue when running build on Netlify. It only happens sometimes.

It had nothing to do for me with Netlify. Happening to me in build. To others in develop. This is a random bug in Gatsby - and it happens so ramdomly that there’s no reproduction, let alone a minimal one.

Same on gatsby v4.15.2. Neither gatsby clean nor yarn install --frozen-lockfile helped. The error also feels very random, each time mentioning other page within the Couldn't find temp query result for (...) error message.

Precisely I’m getting

 ERROR 

UNHANDLED REJECTION Couldn't find temp query result for "/learn-more/en-us".



  Error: Couldn't find temp query result for "/learn-more/en-us".
  
  - page-data.ts:104 readPageQueryResult
    [www-2022]/[gatsby]/src/utils/page-data.ts:104:11
  
  - task_queues:60 runNextTicks
    node:internal/process/task_queues:60:5
  
  - timers:442 processImmediate
    node:internal/timers:442:9
  
  - page-data.ts:121 writePageData
    [www-2022]/[gatsby]/src/utils/page-data.ts:121:18
  
  - page-data.ts:232 
    [www-2022]/[gatsby]/src/utils/page-data.ts:232:24

upon running gatsby build.

learn-more is created using createPage API, precisely:

actions.createPage({
        path: `/learn-more/en-us`,
        component: path.resolve(`src/non-cms-pages/learn-more.tsx`),
        context: {
          lang,
        },
      });

Am also having this issue.

@ZeldOcarina Green threads: https://en.wikipedia.org/wiki/Green_thread - and Node.js itself uses green threads for “concurrency”, while some other language may or may not use it. “Concurrency” and not concurrency because Node.js has GIL: https://en.wikipedia.org/wiki/Global_interpreter_lock, though it’s still more concurrent than other languages with GIL because I/O waits put its green thread in sleep mode, and a different non-blocked green thread is running.

I do! https://www.gatsbyjs.com/dashboard/e968afff-0cff-4103-8d02-5dbbe05c6a6f/sites/26587904-b4fa-402f-b570-2cb1bbabca80/builds/61d86c44-1010-4154-a00e-f82d681b9823/details#rawLogs If you check inside that project there are so many of these builds failing while locally these are working!

As an additional data point, I too am observing relief from this issue with GATSBY_CPU_COUNT=4 and no discernible difference in build times on Netlify. This makes me wonder if this is partly related to resource contention of virtualized CPUs.

@graysonhicks I can’t reproduce this consistently with our full app and we’ve been suffering from it for weeks. If the error message was able to narrow down the source it might be viable to provide a minimal reproduction, but as it stands, I don’t think it’s plausible outside of cases where it arrives through obvious user error.

For the record, I tried a solution similar to the one posted by @jasonlav above and I am still running into this.

I’m getting the same issue on netlify when running build. Sometimes clearing the netlify cache fixes but not always.

@belfz Your reproduction shows the problem because you’re using the createPage action in the wrong lifecycle hook. It’s only allowed in createPages while you use it in onCreateWebpackConfig.

@ascorbic The PR https://github.com/gatsbyjs/gatsby/pull/35968 should fix this, wasn’t easy to spot this 😅

Still observing this issue - random pages error as @belfz mentioned. Updated my build Netlify commands to gatsby clean && gatsby build and issue seems to have resolved itself.

I built a custom front end used the Gatsby Shopify Starter - https://github.com/gatsbyjs/gatsby-starter-shopify

Also, feel like it’s worth mentioning that I experience the same error for local builds and running gatsby clean solves it as well 🤷

I’ve had some success setting GATSBY_CPU_COUNT=2.

I don’t want to jinx it, b/c it’s still not a terribly large sample size, but this has shown improvements for us. I was getting the temp query failure intermittently, but it’s been clear for a bit. 🤞 It doesn’t seem to significantly affect build times either, which was an initial concern.

I’ll report back if it pops back up or stays clear over a larger sample size.

Also running into this since updating to v4 (from v2). Very intermittent. It definitely seems to happen more frequently with our larger sites. If this issue is related to PQR/LMDB stuff, is it possible to add additional debug logging to it? Or perhaps a way to open up the cache db to try and figure out where things have gone off the rails.

I have a netlify instance where it fails maybe 1/6th of the time. I would be willing to possibly run some tests with our data set.

We are not using GatsbyImages in our site.

Same issue, not using jest or even creating pages yet

it has nothing to do with Jest IMO, we started getting this error after upgrading gatsby

I experienced this issue when building pages using nested methods. Removing the nesting appears to have resolved the issue.

Example of what caused the issue

export.createPages = async (args) => {
    await createPageTypeA(args);
};

async function createPageTypeA(args) {
    await createPageInUniversalSharedMethod(args);
}

async function createPageInUniversalSharedMethod({ createPage }) {
   ....
   createPage(...);
    ...
}

Example of what resolved the issue

export.createPages = async (args) => {
    await createPageInUniversalSharedMethod(args);
};

async function createPageInUniversalSharedMethod({ createPage }) {
   ...
   createPage(...);
   ...
}

Oh yeah it’s such a shame that it cannot be deactivated anymore… It often causes troubles and the only opt-out way is to downgrade to v3 which is not optimal…

I run yarn clean && yarn build on every run due to another problem, and I still started having this issue a few days ago

yarn install --frozen-lockfile helped.