Skip to main content
← Back to list
01Issue
FeatureClosedSwamp CLIPublic
AssigneesNone

Relationships

#1282 workflow.run: relay a custom model method's output as method_output (command steps already do)

Opened by ehazlett · 7/19/2026

Problem

Two model-method execution paths behave asymmetrically over the serve WebSocket:

  • A built-in command step streams its subprocess output live as method_output events (kind method_output, carrying a stream and a line) to the caller holding the streaming op.
  • A custom model method produces no method_output at all. Holding the streaming workflow.run op for a workflow whose step runs a custom method, the caller receives only orchestration lifecycle events — validating_inputs, started, job_started, step_started, model_resolved, method_executing, report_completed (a method-summary report), step_completed, job_completed, completed — with or without verbose: true.

The output is not lost — it exists live, server-side. A custom method's structured logger writes to the serve process's own console/log in real time during the run (confirmed: a method's own log lines appear in serve's console, timestamped as the step runs), and to the run-log data artifact. But that run-log artifact is written once, whole, at step completion (not readable while growing), and the live console output is never relayed to the WebSocket client. So a WS client cannot tail a running custom-method step's progress.

Because serve already relays a built-in command step's output as method_output, the capability exists — it is simply not wired for custom-method logger/console output.

Proposed solution

Have the streaming ops (workflow.run, and the direct streaming method-run op) relay a custom model method's logger/stdout as method_output events — the same event shape a built-in command step already produces (kind method_output, a stream field, a line field) — with jobId/stepId for correlation to the emitting step. Gating it behind verbose: true on workflow.run would be fine.

Alternatives considered

  • Poll the step's run-log data artifact and diff by offset — rejected: the artifact is write-once at step completion, not readable while growing.
  • The per-step method-summary report markdown — a post-step summary, not a live tail; nothing arrives during the step.
  • An attach-to-running-run output op (relay a running run's step output to a late subscriber) would also solve it, and would additionally allow tailing a run the caller did not start.

Environment

swamp serve, streaming workflow.run op over the serve WebSocket; observed with a three-step model-method DAG (a custom model method as the middle step). The custom method's own log lines appear live in serve's console but not in the WS event stream. Verified 2026-07-19.

02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED

Closed

9/8/2026, 4:48:16 AM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

stack72 commented 9/8/2026, 4:48:14 AM

Thanks @ehazlett. This is now implemented, so I’m closing it. Custom model methods now relay context.logger output as live method_output events. info is sent on stdout; warning and error are sent on stderr. Workflow runs include the emitting job, step, model, and method for correlation, and the same event stream is relayed for direct method runs over serve. Extension methods should use context.logger for streamed diagnostic output rather than raw console.log.

Sign in to post a ripple.