Read a run trace: follow the data, understand the branches

Start with the run inputs and overall status, duration, and credits used. Expand a node to inspect its incoming value, output, logs, and any error. For a page-summary workflow, check the reading node’s text before investigating the summariser. An inaccurate summary may be faithfully describing the wrong input.

Expressions are references, not guesses about meaning. {{$input}} refers to the connected upstream value; {{read.text}} refers to the text field produced by the node whose ID is read. If a downstream value is missing, compare the expression with the actual recorded output shape. Change the reference or upstream configuration before rewriting unrelated steps.

A Condition node chooses a true or false output. The engine marks downstream nodes as skipped when none of their incoming connections is active. That can be exactly the intended outcome. Follow the chosen output handle and inspect the condition’s log instead of treating every unused branch as an error.

Create a small branch test using a manual input named topic. Add a Condition with the left value below, the contains operator, and the right value billing. Connect its true and false outputs to separate result nodes with distinct result names. Keep the test limited to results, without sending external messages.

{{$trigger.topic}}

1. Run with topic set to “billing question”; inspect the true path and its result.
2. Run again with topic set to “technical question”; inspect the false path.
3. Confirm that the unused result node is skipped in each run.

If a node failed, start with its error and the last successful upstream output. If the run succeeded but the result looks wrong, focus on values and branch decisions. Also check for a simulated-model notice: a completed simulated response is not proof that a live provider accepted your request.

Lists add another dimension. A node that supports fan-out can run once for each input item and return a list of results. Check the list length and per-item logs before assuming a single action occurred. Reduce the input to one or two representative items, change one setting, and compare the next run.

• Keep the original input so a comparison is reproducible.
• Identify the earliest unexpected output, not just the final symptom.
• Test both sides of a branch before relying on it.
• Review final outputs and credit usage after the change.