Summary
buzz workflows delete (NIP-09 kind-5 delete with an a-tag referencing the workflow's UUID) succeeds — the side-effect handler confirms the row is removed from the execution-side workflows table. But buzz workflows list and buzz workflows get keep returning the original workflow content as if it still exists, because the read path replays the raw kind 30620 creation events from the event store without checking for an accepted NIP-09 delete tombstone. Buzz Desktop reads the same path, so deleted workflows also keep showing in the UI.
Evidence (relay logs, buzz-prod_relay_1)
First (successful) deletion pass:
2026-08-28T15:05:07.803970Z INFO Workflow deleted via NIP-09 a-tag (UUID) workflow_id=c3b56fe6-00c9-4565-b322-6b4efc7ca632
2026-08-28T15:05:07.840633Z INFO Workflow deleted via NIP-09 a-tag (UUID) workflow_id=9a777d1a-72e1-40a4-8401-0c61ed80457b
2026-08-28T15:05:07.878658Z INFO Workflow deleted via NIP-09 a-tag (UUID) workflow_id=665955fe-07e1-41c7-8241-2e0a0d556e32
2026-08-28T15:05:07.914583Z INFO Workflow deleted via NIP-09 a-tag (UUID) workflow_id=ce9d823d-ba06-4a91-952d-b7d0a896d71c
2026-08-28T15:05:07.952722Z INFO Workflow deleted via NIP-09 a-tag (UUID) workflow_id=6007b606-c98f-41ff-8721-e5ecfea339ff
2026-08-28T15:08:47.087891Z INFO Workflow deleted via NIP-09 a-tag (UUID) workflow_id=8240d1e1-8580-445b-b161-cd0fe27af541
Subsequent delete attempts on the same IDs (idempotency issue, secondary symptom) fail because the row's already gone from the execution-side table:
2026-08-28T15:13:02.933072Z ERROR Side effect failed: failed to delete workflow 8240d1e1-8580-445b-b161-cd0fe27af541: not found: workflow 8240d1e1-8580-445b-b161-cd0fe27af541
Meanwhile buzz workflows list still returns full content for all 6 workflow IDs, with no indication they've been deleted:
$ buzz workflows list --channel 98e2af42-3043-47f7-8b0e-d26f85916681
[{"content":"name: ping-pong-demo\n...","workflow_id":"8240d1e1-8580-445b-b161-cd0fe27af541"}, ...]
Buzz Desktop shows the same stale list in its workflow view.
Expected behavior
workflows list/workflows get should check whether an accepted NIP-09 delete event (kind 5, a-tag referencing the workflow's coordinate) exists for a given workflow UUID and exclude/tombstone it from the response, matching what the execution-side side-effect table already does.
Secondary issue
Repeated workflows delete calls on an already-deleted workflow return a hard not found error from the side-effect handler instead of a no-op/idempotent success — worth considering for a friendlier UX, though the primary bug above is the one causing user-visible confusion (deleted workflows appearing to still exist).
Environment
- Relay image:
ghcr.io/block/buzz:main, running via podman (buzz-prod_relay_1, buzz-prod_pair-relay_1)
- Reproduced via both
buzz CLI and Buzz Desktop
🐝 Filed by Fizz on behalf of Brada.
Summary
buzz workflows delete(NIP-09 kind-5 delete with ana-tag referencing the workflow's UUID) succeeds — the side-effect handler confirms the row is removed from the execution-side workflows table. Butbuzz workflows listandbuzz workflows getkeep returning the original workflow content as if it still exists, because the read path replays the raw kind 30620 creation events from the event store without checking for an accepted NIP-09 delete tombstone. Buzz Desktop reads the same path, so deleted workflows also keep showing in the UI.Evidence (relay logs,
buzz-prod_relay_1)First (successful) deletion pass:
Subsequent delete attempts on the same IDs (idempotency issue, secondary symptom) fail because the row's already gone from the execution-side table:
Meanwhile
buzz workflows liststill returns full content for all 6 workflow IDs, with no indication they've been deleted:Buzz Desktop shows the same stale list in its workflow view.
Expected behavior
workflows list/workflows getshould check whether an accepted NIP-09 delete event (kind 5,a-tag referencing the workflow's coordinate) exists for a given workflow UUID and exclude/tombstone it from the response, matching what the execution-side side-effect table already does.Secondary issue
Repeated
workflows deletecalls on an already-deleted workflow return a hardnot founderror from the side-effect handler instead of a no-op/idempotent success — worth considering for a friendlier UX, though the primary bug above is the one causing user-visible confusion (deleted workflows appearing to still exist).Environment
ghcr.io/block/buzz:main, running via podman (buzz-prod_relay_1,buzz-prod_pair-relay_1)buzzCLI and Buzz Desktop🐝 Filed by Fizz on behalf of Brada.