We performed a full cache-header audit based on Vercel Support guidance.

next.config.ts:

• has a global /(.*) headers rule
• only adds security headers
• no Cache-Control
• no s-maxage
• no CDN-Cache-Control
• no Vercel-CDN-Cache-Control

src/middleware.ts:

• only adds x-request-id
• does not set any cache headers

There is:

• no vercel.json
• no proxy.ts

The only explicit application cache directives are:

Cache-Control: no-store

on GET-only health routes.

No repository rule matches or modifies:

• /login POST
• Server Action requests
• requests carrying Next-Action

The installed Next.js Server Action runtime explicitly emits:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

No project configuration overrides that header.

What we already tried

1. Created a fresh replacement Preview deployment
2. Confirmed the Preview environment points to the correct backend
3. Successfully purged the Vercel CDN cache
4. Re-ran the test after the purge
5. Added a unique query string to /login on every run to avoid URL cache-key reuse
6. Confirmed the issue still persists
7. Verified /api/health/ready returns 200
8. Verified the login page and referenced initial _next assets load successfully before submitting the Server Action
9. Local Playwright E2E suites all pass
10. Production was not involved in these tests

Even after CDN purge and unique login URLs, the Server Action POST still returned:

x-vercel-cache: HIT

with an x-nextjs-deployment-id belonging to a different deployment.

Vercel Support already confirmed in chat that:

“POST Server Action requests should not be cached or served across deployments with x-vercel-cache: HIT when dynamic no-store headers are set.”

They also stated that, after our repository audit, this behavior warrants investigation by the Support / Edge platform teams.

Questions

1. Why is a POST Server Action response being served with x-vercel-cache: HIT?
2. Why can an immutable Preview deployment hostname receive a Server Action/RSC response associated with another deployment?
3. Which Edge cache layer is storing this response?
4. Why did vercel cache purge --type=cdn --yes not invalidate it?
5. Is there another cache layer for Server Action / RSC payloads that is not affected by the normal CDN purge?
6. Can someone from the Vercel Edge / Next.js platform team investigate this deployment?

I can provide Playwright traces, screenshots, request/response headers, and reproduction details if needed.

1. Open the active immutable Preview deployment.
2. Navigate to /login.
3. Submit valid credentials using the Next.js Server Action.
4. Inspect the POST /login request containing the Next-Action header.
5. Observe:
   • HTTP 303
   • content-type: text/x-component
   • x-action-redirect: /app;push
   • x-vercel-cache: HIT
   • x-nextjs-deployment-id pointing to an older deployment
6. The client then requests stale build-specific _next assets.
7. Those assets return 404 on the active deployment.
8. The browser ends on the Next.js next_error page.