cloudflare/vinext

Pages Router prerender: pages under `/api-...` and lazy catchall pages never finish loading

Geschlossen

#1.542 geöffnet am 22.05.2026

Auf GitHub ansehenContributor Guide
 (0 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)TypeScript (385 Forks)github user discovery
adapter-api-e2ehelp wanted

Repository-Metriken

Stars
 (8.633 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 1T 1h) (462 gemergte PRs in 30 T)

Beschreibung

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 whose path begins with /api-docs/... (an apparent false positive of API-route detection) and lazy fallback catch-all pages (fallback: true) hang waiting for the rendered content. The fallback boundary stays on fallback text and never resolves to the page contents.

page.waitForSelector('#api-docs') timeout

TIMED OUT: /Hi.*?delayby3s/

Estimated Impact

~3 test failures across the deploy suite.

Affected Test Suites

  • test/e2e/prerender.test.ts (3 failures)

Recommendation

  1. Reproduce first in vinext's own test suite. Add a Pages Router page at pages/api-docs/index.tsx and a [...slug] lazy catchall. Verify each finishes loading.

  2. Tighten API-route detection. Match only pages/api/... (with the slash), not the substring api-. Otherwise pages whose path starts with api- are treated as API routes and never render.

  3. Resolve the fallback for lazy catchall. Make sure the prerender fallback resolves to the rendered content once getStaticProps completes.

Part of #1328.

Contributor Guide

Research-Richtung
Untersuchen Sie die Pre Rendering Implementierung von vinext, um zu identifizieren, warum Seiten unter `/api ` fälschlicherweise als API Routen behandelt werden und warum verzögerte Catchall Seiten nie aufgelöst werden. Korrigieren Sie die API Routenerkennung so, dass sie nur `pages/api/` matched, und stellen Sie sicher, dass der Fallback nach Abschluss von `getStaticProps` aufgelöst wird.
Tech Stack
typescriptvitenextjs
Domain
backend
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
2
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Frisch
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
Next.jsVitePages Router
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
50