cloudflare/vinext

App Router: `loading.js` fallback not streamed in initial HTML

Open

#1.528 aberto em 22 de mai. de 2026

Ver no GitHub
 (2 comments) (0 reactions) (0 assignees)TypeScript (329 forks)github user discovery
adapter-api-e2ehelp wanted

Métricas do repositório

Stars
 (8.120 stars)
Métricas de merge de PR
 (Mesclagem média 1d 1h) (462 fundiu PRs em 30d)

Description

This issue was created by an agent analysing CI failures from the Next.js Deploy Suite (vinext main vs Next.js v16.2.6, 2026-05-22).

Problem

Pages that have a slow layout.js/page.js should stream the loading.js fallback content in the initial HTML response. vinext serves an empty body for these tests, indicating the Suspense boundary does not flush the loading fallback before the slow content resolves.

Expected: "Loading..." Received: ""
Expected: "Loading layout..." Received: ""

Estimated Impact

~2 test failures across the deploy suite.

Affected Test Suites

  • test/e2e/app-dir/app/index.test.ts (2 failures)

Recommendation

  1. Reproduce first in vinext's own test suite. Add a slow async server component with an adjacent loading.tsx. Assert the initial response body contains the loading fallback text.

  2. Flush the suspense boundary fallback eagerly. During streaming SSR, emit each Suspense fallback as soon as the boundary suspends, then patch in the resolved content as it completes. Match Next.js's streaming output shape.


Part of #1328.

Guia do colaborador