Question

Next.js getStaticProps fails to fetch to connected database (App Platform)

Posted on October 6, 2023
Deployment
Asked by 0ab18c4071f445e0bd8ef16a1fe517

I’ve implemented getStaticProps for my next.js application which works perfectly locally, but fails on the app platform. The build will hang indefinitely on “pool.query” to the connected database when creating the static images, and will be killed and rebuilt 3 times before failing.

After a lot of testing, I’ve discovered my build works on the app platform when it’s connected to a 3rd party database. I don’t understand why this is the case as my current build on the app platform and my local build can use the connected db.

import { FusionDex } from "../components/components";
import { wrapper, addInitialStore } from "../store/store";
import getInitialStore from "./api/initialStore";

export default function Home() {

  return <>
    <FusionDex />
  </>
}

export const getStaticProps = wrapper.getStaticProps(store => async (props) => {

  try {
    let initialStore = await getInitialStore();

    store.dispatch(addInitialStore(initialStore));

  } catch (error) {
    console.error('Error executing database query:', error);
  }
})

[2023-10-06 20:53:57] │ Static worker unexpectedly exited with code: null and signal: SIGTERM
[2023-10-06 20:53:57] │ 
[2023-10-06 20:53:57] │ > Build error occurred
[2023-10-06 20:53:57] │ Error: Static page generation for / is still timing out after 3 attempts. See more info here https://nextjs.org/docs/messages/static-page-generation-timeout
[2023-10-06 20:53:57] │     at onRestart (/workspace/node_modules/next/dist/build/index.js:678:39)
[2023-10-06 20:53:57] │     at Worker.exportPage (/workspace/node_modules/next/dist/lib/worker.js:95:40)
[2023-10-06 20:53:57] │     at processTicksAndRejections (node:internal/process/task_queues:96:5)
[2023-10-06 20:53:57] │     at async /workspace/node_modules/next/dist/export/index.js:522:32
[2023-10-06 20:53:57] │     at async Span.traceAsyncFn (/workspace/node_modules/next/dist/trace/trace.js:105:20)
[2023-10-06 20:53:57] │     at async Promise.all (index 2)
[2023-10-06 20:53:57] │     at async /workspace/node_modules/next/dist/export/index.js:512:9
[2023-10-06 20:53:57] │     at async Span.traceAsyncFn (/workspace/node_modules/next/dist/trace/trace.js:105:20)
[2023-10-06 20:53:57] │     at async /workspace/node_modules/next/dist/build/index.js:1303:21
[2023-10-06 20:53:57] │     at async Span.traceAsyncFn (/workspace/node_modules/next/dist/trace/trace.js:105:20)
[2023-10-06 20:53:57] │ building: exit status 1
[2023-10-06 20:53:57] │ ERROR: failed to build: exit status 1

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Bobby Iliev

Site Moderator

• October 8, 2023

Accepted Answer

Hi there,

Indeed, during the build process, your app would not have access to the Managed Database cluster in case that you have the trusted sources enabled.

If possible, what I would suggest is that if you have a migrations step, you could move that step from the build process to the deployment process.

The benefit of doing this is that, if your build is successful and the changes to the database are executed, but the deployment fails, then you might end up with the new database schema but with your old codebase which might not be backward compatible.

If this is not applicable in your case, what you could do is to disable the trusted sources so that the database will be accessible during the build process.

Let me know how it goes!

Best,

Bobby