render_timeout

HTTP 504 · code: "render_timeout" · type: https://docs.formfeed.dev/errors/render-timeout

Ein Schritt des Renderings hat länger gedauert als sein Limit. Für das Rendering als Ganzes gibt es kein Limit; jeder Schritt hat sein eigenes:

Schritt	Limit	detail
Die Vorlagensprache (Jinja2, Handlebars) befüllt die Vorlage mit den Daten	5 Sekunden	Template render took 6120 ms; the limit is 5000 ms
Chromium lädt das Dokument, bis keine seiner Anfragen mehr läuft (wie, sagt waitFor.networkIdle)	30 Sekunden	Render exceeded 30000 ms
Warten, bis ein Element zu waitFor.selector sichtbar ist	waitFor.timeoutMs, standardmäßig 5 Sekunden, höchstens 30	Render exceeded 30000 ms (die Meldung nennt in jedem Fall 30 Sekunden)
Das Bild einer Bildausgabe aufnehmen, oder das Element von image.clipSelector	30 Sekunden	Render exceeded 30000 ms
Das PDF drucken	120 Sekunden	Printing the PDF exceeded 120000 ms
Eine Word- oder PowerPoint-Vorlage befüllen	10 Sekunden	Template render took … ms; the limit is 10000 ms
Eine Word- oder PowerPoint-Vorlage oder ein an /pdf/convert gesendetes Dokument in PDF umwandeln	60 Sekunden für das ganze Rendering bzw. die ganze Umwandlung	The conversion did not finish in time
Eine E-Rechnung erzeugen oder eine PDF/UA-1-Datei validieren	20 Sekunden	The e-invoice conversion did not finish in time, The PDF/UA validation did not finish in time

Ein Dokument von mehreren hundert Seiten druckt in einigen zehn Sekunden, weit innerhalb seines Limits. Eine Pause mit waitFor.delayMs hat kein eigenes Limit und ist auf 10 Sekunden begrenzt. Eine Liquid-Vorlage, die länger als 5 Sekunden läuft, antwortet stattdessen mit template_runtime_error, und ein url-Rendering, dessen Seite nicht in 30 Sekunden lädt, mit navigation_failed.

Auch Handlebars-Partials, die tiefer als 8 Ebenen verschachtelt sind, antworten mit diesem Code (Partials nest deeper than 8), obwohl keine Zeit abgelaufen ist. Jinja2 und Liquid haben keine solche Tiefengrenze.

Das Rendering wird als fehlgeschlagen aufgezeichnet und kostet nichts. Wie lange ein Rendering dauern darf zeigt dieselben Limits aus Sicht der Anfrage.

Beispiel

{
  "type": "https://docs.formfeed.dev/errors/render-timeout",
  "title": "Render timed out",
  "status": 504,
  "detail": "Render exceeded 30000 ms",
  "code": "render_timeout",
  "location": null,
  "render_id": "rnd_7da09ab6cd9946b798c187c2a9350852",
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Häufige Ursachen

• Eine Vorlage, die über sehr große Daten iteriert oder Schleifen tief verschachtelt.
• Bilder, Schriften oder Skripte von einem langsamen Server: Das Dokument gilt erst als geladen, wenn keine seiner Anfragen mehr läuft.
• Ein Skript, das das Netzwerk beschäftigt hält, etwa durch Polling oder einen Analytics-Beacon.
• Ein waitFor.selector, der nie sichtbar wird, weil das Skript, das das Element einfügt, fehlgeschlagen ist, der Selektor nicht passt oder das Element verborgen bleibt.
• Eine Word- oder PowerPoint-Datei mit vielen großen Bildern oder Seiten, die LibreOffice langsam umwandelt.

So beheben Sie es

• Verringern Sie die Arbeit in der Vorlage: Berechnen Sie Summen und Gruppierungen in Ihrer Anwendung und senden Sie die Ergebnisse.
• Hosten Sie Bilder und Schriften auf einem schnellen CDN oder in der Dateibibliothek, und prüfen Sie, ob waitFor.selector auf ein Element passt, das Ihr Skript tatsächlich hinzufügt.
• Setzen Sie waitFor.networkIdle auf false für Dokumente, die eine Verbindung offen halten.
• Bei Office-Dokumenten: Komprimieren Sie die Bilder, oder teilen Sie das Dokument auf.

Wiederholen?

Nur, wenn die Ursache vorübergehend war, etwa ein langsamer Bildserver. Eine zu langsame Vorlage scheitert wieder auf dieselbe Weise. Eine Antwort 504 wird nicht unter dem Idempotency-Key gespeichert, eine Wiederholung mit demselben Schlüssel läuft also wirklich. Asynchrone Renderings wiederholt die Warteschlange zweimal, und ein Rendering, das jedes Mal die Zeit überschreitet, endet als worker_exhausted; die Zeitüberschreitung einer Word- oder PowerPoint-Umwandlung wird nicht wiederholt.