Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Expose per-render failure state for buffered SSR consumers

Aperta
  • Qualcosa non va?
#4,125 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
18/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, typescript
Ambito
web-dev

Direzione di ricerca

Start from renderToStream() and the configureServerErrors onError path that the reproduction exercises, since the requested flag must be set where render containment happens rather than where errors are reported. The reproduction script in the issue is the first thing to run; it shows the current calls and hasFailure output for reused errors and escaping server-function failures. Done means each renderToStream() result exposes a read-only, monotonic failure flag that stays true for all three cases without changing hook invocation counts or sanitization.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Use case

A buffered SSR consumer needs to know whether its HTML contains a render failure before publishing it as a successful document. Our concrete use case is serving Markdown from the same rendered page HTML, without browser hydration.

Awaiting renderToStream() intentionally resolves with the HTML produced, including a render where a Loading fragment rejected. onCompleteAll also runs for that case. The documented onError hook reports/maps each error object once, so it cannot act as a per-render integrity signal:

  • Reusing one Error in two requests only notifies the first request.
  • A server-function error first reported as kind: 'server-function' is not reported again as kind: 'render' when it escapes into Loading.

The distinction matters because a server-function failure caught by application code may still produce valid content. Marking every server-function failure would reject those valid renders.

Reproduction

Verified against solid-js and @solidjs/web 2.0.0-rc.15. Run this as an ES module in Node with those packages installed:

import {configureServerErrors,createRequestEvent,renderToStream,ssr,markSafeError} from '@solidjs/web';
import {provideRequestEvent} from '@solidjs/web/storage';
import {configureServerFunctionsServer,registerServerReference,createServerReference} from '@solidjs/web/server-functions/server';
import {createComponent,createMemo,Loading} from 'solid-js';
const calls=[];
configureServerErrors({onError(error,context){calls.push({kind:context.kind,handling:context.handling,url:context.event?.request.url}); if(context.kind==='render'&&context.event) context.event.locals.hasSsrRenderFailure=true; return markSafeError(new Error('Public failure'));}});
configureServerFunctionsServer({wrapInvocation:async run=>{try{return await run()}catch{return (()=>{throw markSafeError(new Error('Public failure'));})()}}});
async function render(id, run){
const event=createRequestEvent(new Request(`https://example.test/${id}`));
const before=calls.length; let didCompleteAll=false;
const html=await provideRequestEvent(event,()=>renderToStream(()=>ssr(['<main>', '</main>'],createComponent(Loading,{fallback:'pending',get children(){const data=createMemo(run);return ssr(['<p>','</p>'],createMemo(()=>data()))}})), {onCompleteAll(){didCompleteAll=true}}));
return {id,didCompleteAll,hasFailure:event.locals.hasSsrRenderFailure??false,hasResolved:html.includes('resolved'),calls:calls.slice(before)};
}
const shared=new Error('PRIVATE_shared');
const results=[];
results.push(await render('reuse-first',async()=>{throw shared}));
results.push(await render('reuse-second',async()=>{throw shared}));
const sf=createServerReference(registerServerReference('probe-failure',async()=>{throw new Error('PRIVATE_sf')}));
results.push(await render('server-function',()=>sf()));
console.log(JSON.stringify(results,null,2));

Observed output:

[
  {
    "id": "reuse-first",
    "didCompleteAll": true,
    "hasFailure": true,
    "hasResolved": false,
    "calls": [
      {
        "kind": "render",
        "handling": "client",
        "url": "https://example.test/reuse-first"
      }
    ]
  },
  {
    "id": "reuse-second",
    "didCompleteAll": true,
    "hasFailure": false,
    "hasResolved": false,
    "calls": []
  },
  {
    "id": "server-function",
    "didCompleteAll": true,
    "hasFailure": false,
    "hasResolved": false,
    "calls": [
      {
        "kind": "server-function",
        "handling": "thrown",
        "url": "https://example.test/server-function"
      }
    ]
  }
]

All three renders complete with the resolved fragment missing. The second and third renders have no render-hook notification. The existing hook behavior matches its once-per-error-object contract; invoking a mapper again is not the requested solution.

Proposed direction

Expose a read-only, monotonic failure flag on each renderToStream() result. Set it at render containment/failure sites independently of error-reporting deduplication, without retaining or exposing error payloads. Consumers can await the render, check this flag and the request lifecycle, and reject incomplete documents.

A contribution is being prepared against next, with coverage for repeated errors across requests, server-function failures that escape versus those caught by application code, contained fallbacks, serialization, concurrent renders and normal streaming. Existing sanitization and hook invocation counts should remain unchanged.

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
11h 49m
PR unite (30g)
346

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.