Skip to content

ChatWalaʻau v0.117.1

Choose a tag to compare

@motojinc25 motojinc25 released this 30 Jul 01:31

This release refines the workflow run experience introduced in v0.117.0: the diagram opens itself, the variable inspector needs no configuration, a workflow that asks questions stays one continuous run, and past workflow turns come back when a chat is reloaded.

No breaking changes. One configuration key is withdrawn (WORKFLOW_STATE_INSPECTOR), but a leftover value in an existing .env is simply ignored -- no action needed. Read the security note below if your workflows handle secrets.

Highlights

The workflow variable inspector is always available (v0.117.1)

  • WORKFLOW_STATE_INSPECTOR is removed. The Variables pane is part of watching a run, and an off-by-default debug mode that has to be discovered, enabled, and redeployed is not a debugging tool anyone reaches for.

⚠️ Security note -- read before upgrading. Key-name redaction (api_key, token, client_secret, ...) and value truncation were designed as defence in depth behind that off-by-default gate. They are now the only protections on workflow variable values. A secret stored under a name the pattern does not recognize -- Local.x, Local.response -- is displayed in the run canvas. There is no setting that turns this off: if your deployment must not surface workflow variables, do not give those users access to the run canvas, and keep secrets out of workflow variables in the first place (the jailed HTTP / MCP / tool handlers hold their own credentials, so a workflow never needs to carry one).

The diagram opens itself (v0.117.1)

  • Sending a message to a workflow brings its canvas up; pressing Diagram first is no longer needed. That button now serves its real purpose -- bringing a canvas back after you close it.

A draggable boundary between the canvas panes (v0.117.1)

  • The graph pane and the step-detail pane can be resized against each other, so a wide graph or a long log can each be given the room it needs.

Fixed: a workflow that asks a question was split into fragments (v0.117.1)

  • Every human-in-the-loop answer used to restart the progress list, open a second assistant bubble, and split the reply -- output produced before the question in one message, output produced after the answer in another. One workflow run read as several disconnected pieces, each having apparently forgotten the last.
  • Four things were behind it: the progress list reset on every resume; the step count restarted at zero on every resume, because it was counted per HTTP turn rather than per run; the resume opened a new message instead of continuing the paused one; and the paused turn was being saved mid-run, which both wrote a partial message that the completing turn then saved again, and fired a session refresh that reset the live progress indicator.
  • A resumed turn now continues the same run, in the same message, with every step it has already shown, the step count continuing from where it left off, and its output appended after a blank line -- exactly as it already looked for a workflow that never pauses. Nothing is saved until the run actually finishes.

Fixed: "Required fields" in the workflow editor would not accept a comma (v0.117.1)

  • On a RequestExternalInput action, typing , erased it -- and the character typed after it -- so a list of more than one field could not be entered at all.
  • The field now keeps what you type and saves the parsed list.

Fixed: the input form stayed on screen after answering (v0.117.1)

  • Answering a Question left its form up until the rest of the workflow finished, inviting a second answer to a question that was already closed.
  • Submit now closes the form immediately and the step returns to running.

Fixed: a reloaded chat now rebuilds its workflow runs (v0.117.1)

  • A past workflow turn shows the same step list it showed live, clicking a step shows its processing log, the Variables pane is there, and Diagram re-opens that run's canvas.
  • Two defects were behind this: the run was never saved beyond a step count, and that count never reached disk either -- the marker shipped in v0.115.1 was silently dropped at save time, so a silent workflow turn always reloaded as an empty bubble.
  • Step logs are trimmed when saved -- a session file is not a log store -- so a long or loop-heavy run keeps its most recent entries and is marked as truncated. A step that recorded no log says so instead of showing a blank pane.

Fixed: "Steps outside the diagram" showed a permanent, meaningless row (v0.117.1)

  • The Agent Framework runs helper executors the author never wrote -- an entry join, and a condition evaluator for every If -- and they were reported verbatim, so _workflow_entry appeared on every single run.
  • They are now classified: framework plumbing is omitted from the display entirely, and a condition evaluator is attributed to the If it belongs to. The section lists only steps that genuinely are not in the diagram, and is hidden when there are none.

Fixed: an If step never lit up, and inflated the step count (v0.117.1)

  • The framework runs <id>_eval, never the If itself, so the node you wrote had no status at all while its evaluator was counted as a step.
  • The evaluator now lights up its own If, and framework plumbing is excluded from the count -- so the number and the diagram agree.

Removed configuration

Variable Note
WORKFLOW_STATE_INSPECTOR Withdrawn. The variable pane is always available. A leftover value in an existing .env is ignored; no action required.

Included in this release

This release includes implementation work from:

  • v0.117.1 through v0.117.1

Notes

  • Internal design management content and architecture control artifacts are intentionally omitted from this release note.

Installation

See the repository README for setup and usage instructions.

Version

  • Release version: 0.117.1
  • Previous release: 0.117.0