block / block/buzz

[Bug] Workflow deletes from Desktop are addressed at the caller, not the workflow's author — agent-created workflows are undeletable

Open
#2,671 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
32.7k
Forks
4.3k
Avg merge
1d 13h
Merged PRs (30d)
253

Description

## Describe the bug

Deleting an agent-created workflow from the desktop app appears to succeed — the UI reports success and the row's delete action completes — but the workflow keeps running and stays in the list. Since workflows are commonly created by agents, this makes most workflows effectively undeletable from the UI.

## To reproduce

1. Have an agent create a workflow (kind:30620 authored by the agent's pubkey).
2. In Buzz Desktop, open the Workflows page as the community owner and delete that workflow.
3. Observe: no error, but the workflow remains listed and continues to fire on its trigger.

## Root cause

`delete_workflow` in `desktop/src-tauri/src/commands/workflows.rs` builds the NIP-09 `a`-tag coordinate with the **caller's** pubkey:

```rust
let builder = events::build_workflow_delete(&workflow_id, ¤t_pubkey_hex(&state)?)?;
```

kind:30620 is addressable by `(author, d-tag)`. For an agent-created workflow, `30620::` names a record that does not exist. The relay accepts the kind:5 (a self-addressed delete always passes validation) and deletes nothing; the UI reports success.

Observed live against a hosted relay: the delete event carried `["a","30620::"]` while the kind:30620 event is authored by the agent — the coordinate can never match.

## Expected behavior

Deleting a workflow from the UI removes it: the delete coordinate should name the workflow's actual author, so the relay can act on it.

## Fix

PR #2669 fixes this client-side: fetch the workflow's kind:30620 event first (the same `#d` query `update_workflow` already uses) and build the coordinate from the event's author.

## Environment

- OS: macOS (aarch64)
- Buzz Desktop, current `main` (also reproduced on a release build)
- Hosted relay

## Related issues

- #2242 — relay executes a-tag deletions scoped by the delete's *signer*, so even a correctly-addressed human-signed delete of an agent workflow no-ops server-side. That is the relay half; #2669 is the client half. Both are needed for delete to work end to end.
- #2390 / #1340 — deleted workflows leave their kind:30620 event queryable, producing ghost list entries. Separate bug, deliberately out of scope here.

---
*Posted by Honey, a Buzz agent, on behalf of @chillerno1.*

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.