1
npx create-cedar-app@4.1.0 cedar-vercel-node24-repro --yes --typescript --no-git-init --telemetry false --no-install --node-check false

The only intentional changes are:

• api/src/functions/ping.ts: minimal JSON response function
• vercel.json: uses yarn cedar deploy vercel
• .yarnrc.yml: pins Yarn 4 / node-modules linker

The minimal api/ping function times out with no response bytes received. Runtime logs point to /opt/rust/nodejs.js, not userland code.

Production impact

Our main affected Vercel project is a CedarJS API app deployed as Vercel Node functions.

Affected endpoints include:

• /api/graphql
• /api/inngest
• other Cedar-generated API functions

The request reaches Vercel edge/TLS successfully, but the function invocation hangs before first byte / response headers. Vercel later kills it after our configured timeout.

Known production-style failure example:

1
Time: 2026-05-08 16:31:54 AEST / 2026-05-08 06:31:54 UTC
2
Region: Sydney / ap-southeast-2
3
URL: POST https://core-n3wj0c57s.preview.buildpass.com.au/api/graphql
4
Deployment: dpl_DN5PL4HPz33mkexBkBjAhEkEkg3b
5
Result: request canceled after 30s awaiting headers
6
Vercel request ID: syd1::fzxp8-1778222604740-f03d71bc7f7a

Other affected deployments include:

1
dpl_4hJVFVU1GTfQRshY8A137mGsDC9n
2
dpl_DN5PL4HPz33mkexBkBjAhEkEkg3b
3
dpl_3Qd9okLy6X49YnBf37Eak3tmpQuL

Earliest runtime failure we found

The earliest pulled Vercel runtime 504 evidence was around:

1
2026-05-08 14:47:20 AEST / 2026-05-08 04:47:20 UTC
2
Deployment: dpl_4hJVFVU1GTfQRshY8A137mGsDC9n
3
Domain: api.XXXXXXXXXX
4
Path: POST /api/graphql
5
Status: 504

That deployment completed at approximately:

1
2026-05-08 14:46:19 AEST / 2026-05-08 04:46:19 UTC

So the first visible failures started immediately after the deployment became active.

Runtime evidence

Vercel logs show repeated timeout/runtime bridge failures like:

1
Vercel Runtime Timeout Error: Task timed out after 120 seconds
2
Node.js process exited with exit status: 128

And unhandled rejections inside Vercel runtime internals:

1
Unhandled Rejection: TypeError: Cannot read properties of undefined (reading 'path')
2
    at IncomingMessage.<anonymous> (/opt/rust/nodejs.js:2:14272)

Also:

1
Unhandled Rejection: SyntaxError: Unexpected end of JSON input
2
    at JSON.parse (<anonymous>)
3
    at IncomingMessage.<anonymous> (/opt/rust/nodejs.js:2:14238)

Some traces also include OpenTelemetry/Sentry frames around IncomingMessage handling, but the failing frame itself is in /opt/rust/nodejs.js.

The failure still occurs in a fresh Cedar app with a tiny unauthenticated function.

The runtime stack points into:

1
/opt/rust/nodejs.js

The failing behavior appears related to how Vercel is bridging incoming requests into Redwood/Cedar-style AWS Lambda handler functions.

Cedar custom functions currently use the AWS-style handler shape:

1
export const handler = async (event, context) => {
2
  return {
3
    statusCode: 200,
4
    body: JSON.stringify({ ok: true }),
5
  }
6
}

Relevant Cedar docs:

https://cedarjs.com/docs/how-to/custom-function/

There is already upstream context around Redwood/Cedar using AWS Lambda handler output on Vercel rather than web-standard Request / Response handlers:

• https://github.com/redwoodjs/graphql/issues/12073
• https://github.com/redwoodjs/graphql/pull/12107
• https://github.com/cedarjs/cedar/issues/526

Related Vercel builder/runtime context

The Vercel Redwood builder still appears relevant because Cedar deploys through the Redwood-style Vercel path.

Relevant Vercel release:

https://github.com/vercel/vercel/releases/tag/%40vercel%2Fredwood%402.4.13

We tested multiple Cedar versions, including latest Cedar in addition to latest Redwoodjs, and the failure still reproduced.