fix(app-router): emit vary marker on edge RSC route response

[james-elicx]

Closes #1531

Summary

• Add the expected x-edge-runtime: 1 marker header on edge runtime App Router responses (both RSC and HTML response builders) to match Next.js, which sets this header in edge-ssr-app.ts.
• Without this header the upstream test/e2e/app-dir/app/index.test.ts "should return the vary header from edge runtime" assertion fails — it saw null instead of '1'.

Test plan

• New unit tests in tests/app-page-response.test.ts assert the header is present on both RSC and HTML responses.
• pnpm run check passes (lint, format, types).
• Existing app-page-response, app-page-render, and app-router suites stay green.

[james-elicx]

/bigbonk review

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@1565

commit: ec52be6

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original
web	preview	production

[ask-bonk]

Review

The implementation is correct for the stated goal: adding x-edge-runtime: 1 to the two buildAppPage*Response helpers so the ported Next.js test assertion passes. Tests are well-structured and the comments citing edge-ssr-app.ts are helpful.

Two things worth calling out:

1. Incomplete coverage across App Router response paths

buildAppPageRscResponse and buildAppPageHtmlResponse are only two of many App Router response construction sites. Other paths that build RSC/HTML responses independently (and therefore won't carry this header) include:

• app-page-cache.ts — buildAppPageCachedHeaders() (ISR HIT/STALE responses)
• app-server-action-execution.ts — server action RSC responses (no-revalidation, re-render, redirect)
• app-page-dispatch.ts — interception route responses
• app-page-boundary.ts — boundary fallback RSC responses
• app-page-execution.ts — RSC redirect responses
• app-page-stream.ts — renderAppPageHtmlResponse() (separate HTML response path)
• app-route-handler-response.ts — route handler responses

If the intent is "every App Router response from vinext should carry x-edge-runtime: 1" (since vinext always runs on Workers), these other paths are gaps. Probably fine as a follow-up since this PR is scoped to the specific test failure, but worth a tracking issue.

2. Nuance on what Next.js actually does

In Next.js, x-edge-runtime: 1 is set inside the edge-ssr-app.ts template — it only applies to pages that opt into runtime = 'edge'. Standard Node.js App Router pages do not get this header. vinext's choice to emit it unconditionally (since all responses are edge-equivalent on Workers) is a reasonable divergence, and the comment in the code explains the rationale well. Just flagging it as context.

Verdict

Looks good. The fix is minimal, targeted, and correctly addresses the test failure from #1531.

[ask-bonk]

Review posted on PR #1565. Here's a summary:

The fix is correct and well-scoped. It adds x-edge-runtime: 1 to both buildAppPageRscResponse and buildAppPageHtmlResponse, which directly addresses the test failure from #1531. Tests pass (26/26).

I flagged two observations in the review:

1. Incomplete coverage — There are ~7 other App Router response construction paths (cached responses, server actions, interception routes, boundary fallbacks, route handlers, etc.) that build responses independently and won't carry this header. Fine as a follow-up if the intent is full coverage.

2. Behavioral nuance — In Next.js, x-edge-runtime: 1 is only set for pages that opt into runtime = 'edge', not all App Router pages. vinext emitting it unconditionally is a reasonable deliberate divergence (since Workers are always edge-equivalent), and the code comments explain this well.

github run