Debugging Blueprints

Run the flow in simulation with the console open and watch where it diverges from what you expect. RUAL has no try/catch, so check the success and error pins of every block that can fail.

Looking for the fix to a specific symptom? Start with Common Issues & Fixes. Execution semantics (dataflow, parallel branches and error handling) are in Block Execution.

Use the console to see what a flow did

The blueprint console shows execution details for your flows. Activate it through the Options menu in the top right of your blueprint, then run the flow, for example through simulation mode, and watch the console output to pinpoint where behavior diverges from what you expect.

console panel

Simulate blocks and functions with test values

Blocks at the beginning of a flow feature a play icon. It opens a popup where you can switch between play modes, activate the current mode (default is simulation), and adjust simulation values.

Each out-pin of the starting block can be given a test value, which is passed to the connected blocks as the simulation traces through the flow. You see the output at every step without touching real traffic. The web update blocks do nothing in a simulation, because there is no browser to update.

simulation popup

Simulation values must be formatted according to their pin type, or the simulation will not produce the results you expect:

Use a production run when a bug needs real data

A simulation executes nothing for real. Production, in the play mode options, runs the flow as if it were live, side effects included: it writes real documents and sends real mail. Use it only on a flow you are sure of, or one that only reads.

On a current core what you saved is what runs for your users. If a simulation works but users still see a failure, check that the change is saved and the blueprint is active. See Blueprint not saving or changes lost.

The audit log shows who changed what

Every blueprint modification is automatically logged: like git commits, but with real-time collaboration. It is the first place to check when a flow that used to work suddenly behaves differently.

• Whole blueprint: open the audit log through the Options menu in the top right of the blueprint.
• Single block: click the block's options () and select Revisions to see only the changes affecting that block.

block revisions

Errors arrive on pins, not as exceptions

RUAL has no try/catch mechanism. When a block fails, the flow does not stop. Blocks that can fail expose their result through output pins:

• success. A condition pin that is true when the operation succeeded and false when it failed.
• error. A value pin containing the error message when the operation fails.

A typical error payload looks like this:

{
  "success": false,
  "error": "Document not found for the given GUID"
}

Always connect and inspect these pins on blocks that perform storage operations, HTTP requests, or anything else that can fail. An unconnected error pin means failures pass silently. See Error Handling for the common handling patterns.

error pins

The table below maps frequent error symptoms to their likely cause and the first thing to check:

Test a tangled flow in four steps

1. Isolate

   Narrow the problem down to the smallest flow (or function) that still shows the wrong behavior. Use the block Revisions to confirm nothing changed unexpectedly.

2. Simulate

   Run that flow in simulation mode with controlled values in the correct pin-type format, and trace the output at each step.

3. Verify pins

   Check that every block along the path receives the in-pin values you expect and produces the out-pin values the next block needs. Pay special attention to success and error pins on storage and HTTP blocks.

4. Confirm against production data

   If simulation passes but the live flow still fails, repeat the run in Production mode to rule out data-dependent issues, knowing that it has real side effects.