SSR Function crashing from deployed Workspace App

Preliminary Checks

This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

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

Initialise a netlify app using the ☝️ example repo.
Set up netlify Site & set Deploy settings to deploy; see below for the settings used in the failing context.
Deploy the site; the deploy should Succeed, but on visiting the Netlify URL you should get the crash report as mentioned above

...

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 ...

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_

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?

gatsby/packages/gatsby/src/utils/page-ssr-module/lambda.ts

Lines 34 to 35 in 9584173

    
           // 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 😊

Looks like #39005 might fix this?

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