Workflow send_message cannot target a different channel; runs fail silently

[Dirtywater97]

Summary

A workflow whose send_message step targets a different channel than the one the workflow is bound to always fails. The run is created and accepted, then dies at the first step with no user-visible error. From the outside it looks like "workflows silently do nothing."

Repro

1. Create a workflow in channel A:

name: Recycle to Kaizen
trigger:
  on: reaction_added
  emoji: "♻️"
steps:
  - id: post_candidate
    action: send_message
    channel: <channel-B-uuid>
    text: "## Flagged for Kaizen"
enabled: true

2. buzz workflows trigger --workflow <id> → {"accepted": true, "run_id": "..."}
3. Nothing is ever posted to channel B, and nothing is posted to channel A either.

Cause

resolve_send_message_channel in crates/buzz-workflow/src/executor.rs:468 rejects any channel: override that differs from the workflow's own channel_id:

if override_channel_id != workflow_channel_id {
    return Err(WorkflowError::InvalidDefinition(format!(
        "SendMessage: channel override must match the workflow channel ({workflow_channel_id})"
    )));
}

Since every channel-created workflow has workflow_channel_id = Some(...), the channel: field is effectively write-only — it can only ever name the channel it already posts to. Cross-channel routing is impossible.

Why this is worse than a missing feature

The channel: key is accepted at create time by the schema and by Desktop's workflow form. There is no validation error, no warning, and no run-history surface (see the related issue on run visibility), so the failure is invisible at every layer. Three separate debugging sessions on my side concluded "workflow steps don't execute at all" before reading the source.

Requested

Either:

• (preferred) allow send_message to target any channel the workflow owner is a member of, authorizing on owner membership rather than on workflow binding; or
• reject the workflow at create/update time with a clear error if channel: differs from the workflow channel, so the failure is visible immediately instead of at run time.

Cross-channel routing is the core of most useful reaction workflows — "react with an emoji, file it into the triage channel." Without it reaction_added can only echo into the channel it fired in.

[Tr1ckyMag1ca1]

Independent confirmation on a self-hosted relay, with a different trigger type: this is not limited to reaction_added.

Our greeter agent's door check is a SCHEDULED workflow (cron 0 */15 * * * *) living in #introductions and posting to #housekeeping. It ran for a full day and greeted nobody.

scheduled_workflow_fires shows the scheduler claiming every 15-minute tick on time, all day. Every corresponding row in workflow_runs is status=failed, current_step=0, empty execution_trace, with the same error: "invalid definition: SendMessage: channel override must match the workflow channel (bfe9f062-...)". A message_posted workflow in the same channel failed identically.

Control, fired the same minute: an otherwise identical workflow created IN #housekeeping and posting to #housekeeping completed with sent: true. So it is specifically the override check in resolve_send_message_channel, exactly as you diagnosed.

Strong agreement that the invisibility is what makes this expensive. With run history returning [] (#2980), we also spent a day concluding "the scheduler is broken" before reading Postgres directly.

+1 on the preferred fix, authorize on owner membership. A greeter agent that can only speak in the room it watches cannot route new arrivals anywhere, which is most of the point of having one.