Failed builds - AWS

We are using AWS as a hosting solution for our site. We’ve been experiencing failed Dato builds (using the “build” button within the Dato admin panel) since January 9th of this month. We did not change any settings within the Dato Administration panel nor did we make any commits to AWS CodeCommit for our Dato install.

The logs are showing these errors:

info  - Collecting page data...
/codebuild/output/srcxxxxxxxx/src/.next/serverless/chunks/9769.js:29147
    cookieAttributeList.unparsed ??= []
                                 ^^^

SyntaxError: Unexpected token '??='
    at wrapSafe (internal/modules/cjs/loader.js:1001:16)
    at Module._compile (internal/modules/cjs/loader.js:1049:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:101:18)
    at Object.__webpack_require__.f.require (/codebuild/output/srcxxxxxxxxx/src/.next/serverless/webpack-runtime.js:199:28)
    at /codebuild/output/srcxxxxxxxxxx/src/.next/serverless/webpack-runtime.js:110:40
    at Array.reduce (<anonymous>)

 

> Build error occurred
Error: Failed to collect page data for /[slug]

And from another part of our log:

> snappy@6.3.5 install /usr/local/lib/node_modules/serverless/node_modules/snappy
> prebuild-install || node-gyp rebuild
prebuild-install WARN install EACCES: permission denied, access '/root/.npm'
gyp WARN EACCES current user ("nobody") does not have permission to access the dev dir "/root/.cache/node-gyp/14.19.2"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/serverless/node_modules/snappy/.node-gyp"
gyp WARN install got an error, rolling back install
gyp WARN install got an error, rolling back install
gyp ERR! configure error 
gyp ERR! stack Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/serverless/node_modules/snappy/.node-gyp'
gyp ERR! System Linux 4.xx.xxx-xxx.xxx.xx.xx
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/local/lib/node_modules/serverless/node_modules/snappy
gyp ERR! node -v v14.19.2
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok

What could be the issue here?

Hello @fbrown

When it comes to the build process, we have no access of how it is made through Dato:

Dato only makes available the information inserted in the dashboard through an API, which is then requested and rendered through your projects code, outside of Dato.

If you are having build issues, it indicates a problem in the process of rendering/requesting the information directly on your code.

Since Dato doesn’t have access to the code used to deploy your project, we are unable to identify what may be causing those build issues, as only the backend/front-end developers for your projects code can do so.

If they are getting unexpected responses, or issues with any requests made to dato, please let us know and we can take a look on our end at what could be happening.

Or, if they seem to be having an issue with a specific part of the code that seems to be crashing the project, also let us know and we will try and help to the most of our capabilities

Some good pointers to where the issues could arise from are:

If you changed a “slug” field, or a field that can be used as a slug, this can create some problems depending on how your code is generating routes/fetching records.

If your project is filtering for some field value to fetch a record, changing that value can make your project no longer fetch that record for rendering.

Any other more in-depth pointers can only be given by a developer that has access to the code and can see how the records are being fetched/rendered.

If you are still running into some issues after checking the fetching-rendering code you can send us an email at support@datocms.com with the project repository so we can take a look on our end what could be causing this.

1 Like