Skip to main content

template_runtime_error

HTTP 422 · code: "template_runtime_error" · type: https://docs.formfeed.dev/errors/template-runtime

The template compiled, but failed while it ran with the data of this request. Nothing was printed; the render is recorded as failed and costs nothing.

location gives line and column where the template language knows them, in the body, the header or the footer (the problem does not say which), and is null where it does not. For a Word or PowerPoint template it names the part of the file.

Example​

{
  "type": "https://docs.formfeed.dev/errors/template-runtime",
  "title": "Template runtime error",
  "status": 422,
  "detail": "filter not found: strftime",
  "code": "template_runtime_error",
  "location": { "line": 12, "column": 17 },
  "render_id": "rnd_7da09ab6cd9946b798c187c2a9350852",
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Common causes​

  • An unknown helper or filter. Liquid runs with strict filters, so a typo stops the render instead of printing nothing.
  • A calculation that came out as NaN reached money, number or numToWords: arithmetic on a value that is text ("19 %") or missing. The helpers stop the render rather than print NaN; text that is not a number, such as "on request", they print as it is.
  • A method called on a missing value, for example customer.name.upper() when customer is not in the data.
  • An include of a partial that was never pushed with the template, for example one added to partials/ after the last formfeed templates push (see Partials), or of a shared partial that was deleted, renamed or written for another template language.
  • A partial that includes itself (in Handlebars: Maximum call stack size exceeded).
  • A Liquid template that runs longer than the 5 seconds a template may take. Jinja2 and Handlebars report that as render_timeout.

Rarely, the render service reports a failure of its own under this code, for example a browser that crashed. Then detail does not refer to your template at all. Retry once, and if it repeats, send the request_id to support@formfeed.dev.

How to fix it​

  • Reproduce it with the same data: paste the request data as a data set in the editor, or save it as data/failing.json in the template folder and run formfeed validate <slug> --data failing. If the workspace keeps render requests, formfeed renders pull <id> fetches the data of the failed render; see Reproduce a failed render.
  • Guard optional values with default or an if.
  • Check the name in the helper reference.

Retry?​

No, unless detail is not about your template. Fix the template or the data first, then send the request again with a new Idempotency-Key or without one: a 4xx answer is stored under its key for 24 hours, so the old key returns this problem again. See retrying.