Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSR Function crashing from deployed Workspace App #38986

Open
2 tasks done
amaccann opened this issue May 21, 2024 · 2 comments
Open
2 tasks done

SSR Function crashing from deployed Workspace App #38986

amaccann opened this issue May 21, 2024 · 2 comments
Labels
status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer type: bug An issue or pull request relating to a bug in Gatsby

Comments

@amaccann
Copy link

Preliminary Checks

Description

I think there's a problem when deploying a SSR gatsby app from a yarn workspace app, deployed to netlify: when deployed to netlify, the SSR engine crashes on initial invocation. here's the stacktrace:

An unhandled error in the function code triggered the following message:

Error - ENOENT: no such file or directory, lstat '/var/task/.cache/data'

Stack trace
Error: ENOENT: no such file or directory, lstat '/var/task/.cache/data'
    at Object.lstatSync (node:fs:1666:3)
    at Object.lstatSync (/var/task/node_modules/graceful-fs/polyfills.js:318:34)
    at statFunc (/var/task/node_modules/fs-extra/lib/util/stat.js:24:20)
    at getStatsSync (/var/task/node_modules/fs-extra/lib/util/stat.js:25:19)
    at Object.checkPathsSync (/var/task/node_modules/fs-extra/lib/util/stat.js:64:33)
    at Object.copySync (/var/task/node_modules/fs-extra/lib/copy/copy-sync.js:27:38)
    at setupFsWrapper (/var/task/apps/gatsby-test/.cache/page-ssr/lambda.js:153:10)
    at Object.<anonymous> (/var/task/apps/gatsby-test/.cache/page-ssr/lambda.js:172:16)
    at Module._compile (node:internal/modules/cjs/loader:1364:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1422:10)

From what I can interpret in the stacktrace, the problem may be that /var/task/.cache/data is not found as the path is incorrect in that execution scope; I think it should be /var/task/apps/gatsby-test/.cache/data (see setupFsWrapper in the trace).

The SSR engine initialised fine in the supplied repo, when the gatsby instance was in the root of the repo ... however, in moving it into a yarn workspace context, the above problem then appears. So It seems like gatsby's SSR engine expects a "root" path throughout? Hopefully it's clear & the answer simple as the inability to deploy a gatsby site within workspaces is a problem ...

Reproduction Link

https://github.com/amaccann/gatsby-renofi-test

Steps to Reproduce

  1. Initialise a netlify app using the ☝️ example repo.
  2. Set up netlify Site & set Deploy settings to deploy; see below for the settings used in the failing context.
  3. Deploy the site; the deploy should Succeed, but on visiting the Netlify URL you should get the crash report as mentioned above
Screenshot 2024-05-21 at 11 39 59

...

Expected Result

Site should render fine, specifically the paths using SSR engine's output (in this case, a simple public GQL I have access to)

Actual Result

When visting the deploy URL, the URL should simply report Invocation failed and a crash stacktrace as below ...

Screenshot 2024-05-21 at 11 41 30

Environment

Slightly redundant, given the issue is upstream in `netlify`; however...



  System:
    OS: macOS 14.4.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.16.0 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 9.5.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 125.0.6422.61
    Safari: 17.4.1
  npmGlobalPackages:
    gatsby-cli: 5.13.3


### Config Flags

_No response_
@amaccann amaccann added the type: bug An issue or pull request relating to a bug in Gatsby label May 21, 2024
@gatsbot gatsbot bot added the status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer label May 21, 2024
@amaccann
Copy link
Author

amaccann commented May 22, 2024

Not sure what the policy is re. commenting, or if the Issue tab is being actively audited ... but I think this may be the problem?

// TODO: don't hardcode this
const cacheDir = `${process.cwd()}/.cache`

Because when I check the output of the Function in netlify logs, I can see the rewrites are all taking place form the root of the (mono)repo, NOT the root of the monorepo app being started. Each of those rewrites is taking ${process.cwd()}/.cache as the origin, not adjusting for where the app was built from.

May 22, 08:45:25 AM: ba81e0e6 2024-05-22T07:45:26.352Z	undefined	INFO	Preparing Gatsby filesystem {May 22, 08:45:25 AM: ba81e0e6   from: '/var/task/.cache',
May 22, 08:45:25 AM: ba81e0e6   to: '/tmp/gatsby/.cache',
May 22, 08:45:25 AM: ba81e0e6   rewrites: [
May 22, 08:45:25 AM: ba81e0e6     [ '/var/task/.cache/caches', '/tmp/gatsby/.cache/caches' ],
May 22, 08:45:25 AM: ba81e0e6     [
May 22, 08:45:25 AM: ba81e0e6       '/var/task/.cache/caches-lmdb',
May 22, 08:45:25 AM: ba81e0e6       '/tmp/gatsby/.cache/caches-lmdb'
May 22, 08:45:25 AM: ba81e0e6     ],
May 22, 08:45:25 AM: ba81e0e6     [ '/var/task/.cache/data', '/tmp/gatsby/.cache/data' ]
May 22, 08:45:25 AM: ba81e0e6   ]
May 22, 08:45:25 AM: ba81e0e6 }

So it seems like that TODO: don't hardcode this was the developer noting that at some point this needs to be more configurable 😊

@amaccann
Copy link
Author

amaccann commented Jul 2, 2024

Looks like #39005 might fix this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer type: bug An issue or pull request relating to a bug in Gatsby
Projects
None yet
Development

No branches or pull requests

1 participant