Runs & run data

Every test run records, for every executed node, the entire data envelope that crossed each wire — not a truncated preview, not just the payload. When you debug, you are looking at exactly what the engine saw. This page explains what’s captured, where it lives, and the tools built on top of it.

The envelope

Data between nodes travels in an envelope: the working payload plus its content type and length, creation/modification timestamps, a correlation id, and the trace (run id, node id, span). Surfaces that display run data show the whole thing — it’s a hard product rule — because the metadata is exactly what you need when something’s wrong: which run, when did the payload change, what content type did that service actually return.

Why this matters day to day:

• Field paths come from reality. Right-click any field in the viewer → Copy Flowdrome path → paste the expression into a node property. No guessing at shapes from API docs.
• JSON inside strings expands. An HTTP response body that arrives as a JSON string renders as an expandable tree (a {} JSON pill marks it) — you inspect it, and expressions can descend into it, without a parse step.
• Binary is first-class. Files and images flow as binary items with metadata, not base64 blobs mangled into JSON.

Per-port capture

Multi-input nodes record each input port separately. A Merge node’s run view has an All inputs / Input 1 / Input 2 selector, so “what exactly arrived on the second input?” has a first-class answer — which is the question you’re actually asking when a join misbehaves.

Big data stays fast

Large node payloads (hundreds of rows, tens of kilobytes and up) are captured in full but shipped deferred: the run view receives a small descriptor (row count, byte size, a preview) and fetches windows of rows on demand as you scroll. A 100,000-item run opens in milliseconds; the data is still all there, server-side. The same windowing protects the live debugger and the host dashboard’s run drawer (“Load full data”).

The Console

Runs also carry a console feed — a timestamped stream that renders in a floating dock during Test/Debug (it opens itself on the first entry) and lands in the Runs tab, saved with the run. Three nodes feed it:

• Console prints a message (with {{ }} expressions) — the printf of workflow debugging.
• Show Image renders a binary image — an AI Image result, a downloaded file — inline in the feed, live during the run and preserved in the run record.
• Play Audio embeds an inline audio player for binary audio (an AI Speak reply, a file); new entries auto-play during a Test/Debug run, with a mute toggle in the dock header.

Retention & archived runs

Three layers, from hot to durable:

• The test host keeps a configurable number of recent runs in memory (Admin → Test host → retention; default 25). Beyond that, run summaries remain listed but the details are evicted — such rows render dimmed.
• Summaries are durable: they’re persisted to the Nucleus’s embedded database and survive restarts.
• Saving a workflow embeds its recent runs in the document (meta.runs). Reopen the workflow months later — or on another Nucleus after an import — and those runs appear with an ARCHIVED chip, fully openable. Your reference run travels with the workflow.

Comparing runs

Runs → Compare diffs any two envelopes — within one run or across runs (every recent run’s envelopes are offered, grouped per run). Added/removed/changed highlighting, an only-differences toggle, and a scope switch: Full envelope (default — timestamps and trace included) or Payload only. JSON held in strings is parsed for field-level diffs, so two HTTP responses diff by body field, not as two giant strings.

Typical uses: “what did this step change?” (its input vs its output — the default picks), and “why did today’s run differ from yesterday’s?” (same node, two runs).

Performance, in detail

The Runs tab’s Performance card rolls the whole run up: payload bytes in/out across every node boundary, throughput (MB/s and items/s where nodes processed item lists), and the peak worker memory observed. Next to it, slowest steps names the bottleneck.

Below the totals sit phase timings: nodes that do expensive multi-step work report where the time went — the SQL node splits connect (socket + TLS + auth) from query, the HTTP nodes time the request itself. Phases show as chips on the Performance card (summed across the run) and on each node’s duration tooltip, and they ride the telemetry stream to your log platform. So “the SQL node took 900ms” becomes “870ms of it was connection setup — pool or move the database”.

Retry from a node

A failed (or merely suspicious) run can be retried from any node: Flowdrome rebuilds the downstream subgraph and seeds it with the run’s recorded input envelopes at that node — then runs it as a brand-new run of the same workflow. Upstream is not re-executed: no webhook re-fired, no email re-sent, no API double-billed. The data you already captured is the fixture.

The Runs view surfaces this as a Retry from step button on failed runs; together with the slowest steps card (top three by duration, the worst flagged as the bottleneck) it makes the Runs tab the place where both correctness and performance questions get answered.

On the hosts

Deployed apps keep their own run history with the same envelope model (capture budgets are configurable per app — see the host’s Settings tab). The host aggregates a run ledger across its apps: start/end records the host itself preserves in its embedded database, so an app’s operational history survives the app rotating its own records (“preserved by host” rows in the dashboard). App logs stream to the host and through the Nucleus’s logs drawer; per-app CPU/memory/disk telemetry lives in the host’s Resources tab with selectable history ranges. See the Hosts guide for captures of all of it.