Viewing a submission's processing trace

Two independent Settings toggles control how much visibility you have into a submission's validate.js/process.js/PDF-render pipeline - both off by default:

• Generate debug.log - writes the full trace to debug.log, saved alongside the generated PDF in the shared Yatate/Output folder, for every submission from then on. A persistent, on-disk record. A filtered, error-only mirror, error.log, is written alongside it every time - always overwritten, even to empty on a run with no errors, so a script or wrapper tool can just check whether it's non-empty rather than parsing debug.log itself. (Unrelated to CSV batch's own per-record export_errors.log - that's a separate file, one line per failed record.)
• Show Debug Log in Preview - adds a Processing Log button (a terminal icon) to Output Preview's toolbar. Click it to open a full-page, read-only view of that specific submission's trace - the same content debug.log would contain, right in the app. When this trace hit an actual error, the Processing Log opens automatically as soon as the preview loads, instead of waiting for you to click the button.

The two are independent. The in-app Processing Log is always captured per submission regardless of whether Generate debug.log is on - that setting only controls whether the same trace is also written to disk. Turn on Show Debug Log in Preview alone for quick checks while authoring; add Generate debug.log too when you need a persistent record you can send someone or check later (a deployed kiosk you can't watch live, for example).

The Processing Log button's icon changes to flag trouble before you even open it: amber if the trace has a warning, filled red if it hit an actual error (e.g. process.js itself threw and processing stopped). On disk, a warning/error line is prefixed WARN: /ERROR: - a plain, greppable convention external tooling can scan debug.log/error.log for without needing to understand the app's own internal log shape.

console.error(msg) in process.js/validate.js is a clean way to bail out of your own script with an explanation - it records the message as an ERROR: line, then halts the rest of the script, same as any other uncaught script error.

A computed value in process.js doesn't show up

1. Did you assign it onto inputs, not a local variable? Only a new inputs property forwards to blocks.
2. Is the property name actually new? Reassigning inputs.options = ... to the same name a submitted field already used is silently ignored - compute into a different name (inputs.optionsFormatted).

A block renders nothing, with no error

Usually by design: an image block with no source, a QR block with empty data, or a grid whose data evaluates to an empty array (or errors - a broken expression fails silently, same as everywhere else) all just omit themselves rather than showing a broken placeholder.

Layout looks right in the editor but the printed PDF differs

The Overlay Editor only shows page 1 - content placed on page 2+ via hand-edited page properties won't be visible while editing, only in the final PDF. See "Viewing a submission's processing trace" above for how to get a full trace to compare against.