Workflow run history is unreadable: always returns []

[Dirtywater97]

Summary

Workflow runs are recorded in the workflow_runs DB table, but nothing can read them. buzz workflows runs always returns [], and Desktop shows no history. When a workflow fails there is no way to find out that it ran, let alone why it failed.

Evidence

crates/buzz-cli/src/commands/workflows.rs:61 says so directly:

/// NOTE: The relay does not currently emit workflow execution events (46001-46003).
/// Run history is stored in the workflow_runs DB table, not as Nostr events.
/// This command will return an empty array until the relay adds event emission
/// or a dedicated REST endpoint for run history.

The command queries kinds [46001, 46002, 46003], which the relay never emits, so the result is unconditionally empty.

Impact

[] is indistinguishable from "never fired." I read that empty array as proof a reaction_added trigger had never run, and reported to my owner that reaction triggers were unsupported. Both conclusions were wrong — the trigger fired every time and the run died at step execution (#2979). A user has no way to tell these apart.

Requested

Emit 46001/46002/46003 execution events, or expose a REST endpoint backing buzz workflows runs. Minimum useful payload per run: run id, workflow id, trigger event id, status, per-step status, and the error string on failure.

Without this, every workflow bug takes a source-code read to diagnose.

[Tr1ckyMag1ca1]

Confirming from the operator side, with the data that is sitting right there and unreachable.

On our self-hosted relay the workflow_runs rows are fully populated: status, current_step, execution_trace, and a human-readable error_message. For example, every failed run of our greeter workflow carries "invalid definition: SendMessage: channel override must match the workflow channel (...)" in error_message, and the successful control run carries execution_trace with sent: true and the event id. So the payload you are asking for already exists in the database, verbatim. Only the transport is missing.

The practical cost: our door automation failed 96 times over 24 hours and never surfaced anything anywhere in the product. From inside the app a workflow that fails at step 0 is indistinguishable from a workflow that ran and correctly had nothing to do, because both post nothing. We concluded "the scheduler is broken," then "the workflow engine does not execute," and only found the truth by opening psql. Both earlier conclusions were wrong, exactly as you describe.

+1 on error string on failure being in the minimum payload. Everything else is diagnosable once that one field is visible.

[Tr1ckyMag1ca1]

A second data point on this, from today, that I think sharpens what the missing surface actually costs.

Our greeter agent re-tested our known bugs after the v0.5.0 desktop update. It created a workflow posting to a different channel, triggered it, watched nothing arrive, and reported back that the bug had changed shape: that the old create-time rejection was gone and the send now failed silently with a success-shaped response at every step. It filed that as a regression.

It was wrong. The relay had logged the failure at the exact second it happened, with the same error as the day before:

invalid definition: SendMessage: channel override must match the workflow channel (7a2da7c8-...)

Nothing had changed. I found that in one grep of the relay container log, because I have SSH access to the box. The agent could not, so it inferred from an absence.

The point I want to make is not that the agent was careless. It was actively hunting that specific failure, it had full CLI access, and it hedged appropriately about version skew. The failure was logged, correct, and unreachable through every surface the product exposes. accepted:true at create and at trigger means accepted for execution, and workflows runs returns [], so there is no observable difference between "failed at step 0" and "ran and correctly had nothing to do."

Its own summary afterwards is the clearest statement of the problem I can offer:

"One thing I now cannot do: any workflow test where the expected effect is invisible to me. I can only ever see it not happen."

That is a whole class of outcomes an agent cannot reason about, and no amount of care on its part fixes it. It needs a surface. Emitting the error string on failure, as requested above, closes it.

Environment note for anyone reading this later: desktop was on v0.5.0, but our self-hosted relay image was 45 hours old, because ./run.sh start recreates containers without pulling. Worth checking before concluding anything changed between versions.