buzz workflows delete removes the workflow but leaves its kind:30620 event live, so workflows list and workflows get still return it

[standing-order]

Buzz Version 0.4.26 (0.4.26)
MacOS Sequoia 15.7.5

Summary
Deleting a workflow works: the DB row is removed, the engine cache is invalidated, and the workflow can no longer be triggered. But the kind:30620 definition event is deliberately left un-soft-deleted, and both CLI read commands query that event.

Every surface an operator can inspect reports the workflow as live. The only way to find out it is gone is to trigger it.

Environment
Source read at block/buzz commit a64cc71 (main); relay under test reports version: 0.2.0 via NIP-11 (version match, not commit-exact).
All CLI output below was executed against a live relay.
Reproduction

$ buzz workflows list --channel [ … 6f8ef4ca-697c-47d9-8aea-a0b7800300c4 still present, full YAML … ]

$ buzz workflows get --workflow 6f8ef4ca-697c-47d9-8aea-a0b7800300c4 {"workflow_id":"6f8ef4ca-…","content":"name: Approval Gate Control\n…"}

$ buzz workflows trigger --workflow 6f8ef4ca-697c-47d9-8aea-a0b7800300c4 {"error":"relay_error","message":"relay error 400: invalid: workflow not found"} ```

The delete succeeded. list and get disagree.

Confirmed on two separate workflows. Neither posted its first step after deletion, and both had posted it on every prior trigger, so the trigger failure is corroborated by an observable side effect rather than by the error string alone.

Root cause
cmd_delete_workflow (crates/buzz-cli/src/commands/workflows.rs:139-150) signs a kind:5 whose a tag is 30620:<pubkey>:<workflow_id> (crates/buzz-sdk/src/builders.rs:1498-1508).

handle_a_tag_deletion (crates/buzz-relay/src/handlers/side_effects.rs:1979-2053) dispatches on the kind in the a tag. The KIND_WORKFLOW_DEF arm calls delete_workflow_for_owner and invalidate_channel_workflows, then returns. The generic parameterized-replaceable arm below it — the one that calls soft_delete_by_coordinate so REQs stop returning the event — is never reached, because the workflow arm matched first. The code comment states this is deliberate:

rust // Listed after the workflow branch so workflow's bespoke deletion // (which doesn't soft-delete the `events` row by design — that's a // separate concern) takes precedence.

Meanwhile cmd_list_workflows and cmd_get_workflow (crates/buzz-cli/src/commands/workflows.rs:20-58) both query {"kinds":[30620]}. They read exactly the row the delete path declines to touch.

The two halves are each internally consistent. The disagreement is between them.

Impact
An operator cannot tell a deleted workflow from a live one through any shipped read path.
A definition intended to be retired stays fully readable. Since workflows list returns the complete YAML body to any channel member, a workflow deleted because its content was sensitive is still readable by every member afterwards.
Combined with workflows runs returning [] by construction (documented at crates/buzz-cli/src/commands/workflows.rs:60-65), the CLI's entire workflow-observability surface can disagree with the engine.
Secondary: accepted: true on delete carries no information about the target
$ buzz workflows delete --workflow 00000000-0000-4000-8000-000000000000 {"accepted":true,"event_id":"f5718152…","message":""}

That UUID has never existed. The response reports that the kind:5 event was stored, not that a workflow was deleted — delete_workflow_for_owner returning None is logged and otherwise ignored. An operator who typos a workflow id gets an unqualified success. (We hit this by accident before hitting it on purpose.)

Suggested fix
Soft-delete the event row as well as the DB row. Call soft_delete_by_coordinate from the KIND_WORKFLOW_DEF arm, or let that arm fall through to the generic parameterized-replaceable handler after doing its bespoke work. Either makes list/get agree with trigger.
If leaving the event live is intentional — e.g. definitions are meant to be an append-only audit trail — then cmd_list_workflows should reconcile against the engine, or mark deleted entries, rather than presenting them as current. Whichever way it is decided, the two surfaces should not disagree silently.
Report whether anything was deleted. Have the delete path surface delete_workflow_for_owner's Option so a no-op delete is distinguishable from a real one.
Found by Bumble (Buzz onboarding agent) on 2026-07-25 while deleting test artifacts from an unrelated investigation.

[bonpiedlaroute]

Taking this one — PR coming shortly.

I read both branches of handle_a_tag_deletion
(crates/buzz-relay/src/handlers/side_effects.rs:2002). The KIND_WORKFLOW_DEF
arm returns after delete_workflow_for_owner + invalidate_channel_workflows,
so the generic NIP-33 arm below it — the one calling soft_delete_by_coordinate
— is never reached for kind:30620. Every other addressable kind, kind:30023
included, gets soft-deleted so REQs stop returning it.

I'm proposing to close the gap on the relay side: extract the soft-delete block
into a helper and call it from the workflow arm too, so the events row follows
the DB row. Worth noting soft_delete_by_coordinate is an UPDATE … SET deleted_at = NOW() (crates/buzz-db/src/event.rs:771) — the row is retained,
only its REQ visibility changes, so no definition history is lost.

I'm aware of the comment above the generic arm stating the current behaviour is
deliberate ("doesn't soft-delete the events row by design — that's a separate
concern"). My reading is that the concern it defers is workflow row deletion
semantics, not the visibility of the definition event — but if the intent was
that the kind:30620 event outlives the workflow on purpose, then the fix belongs
in cmd_list_workflows / cmd_get_workflow
(crates/buzz-cli/src/commands/workflows.rs:12-58) instead, filtering out
definitions with no live workflow. Happy to switch to that shape.

Adding an e2e test mirroring test_long_form_a_tag_deletion
(crates/buzz-test-client/tests/e2e_long_form.rs:321), which covers exactly this
path for kind:30023.

[crsmoore]

Happening to us as well, on a hosted *.communities.buzz.xyz community (Buzz Desktop 0.5.2, current CLI). During an agent-to-agent workflow ownership handoff, the owning agent ran buzz workflows delete three times — each returned accepted: true with a signed event ID — and the workflow remained fully visible in both workflows list and workflows get indefinitely (polled every 5s for 90 seconds, re-checked ~10 minutes later). Updates to the same workflow applied within seconds throughout, so from the outside it presented as "deletes silently ignored, updates fine."

The diagnostic in this issue matches exactly: buzz workflows trigger on the "deleted" workflow returns relay error 400: invalid: workflow not found. In plain terms: the delete really did disable the workflow — nothing can run it anymore — but its stored definition record (the kind:30620 event) was left behind, so every listing still shows a "ghost" of a workflow that no longer exists. Two knock-on effects worth making sure the fix covers:

• The ghost is convincing enough that we assumed deletion was broken and neutered the workflow by update (rename + never-fire cron) as a precaution — which, per relay: workflow a-tag deletion leaves current kind:30620 event live — ghost workflows in Desktop list, silent resurrection on edit #2390, is exactly the resurrection-on-edit trap. A delete that visibly deletes would have prevented that whole detour.
• On a hosted community there's no operator access to verify engine state, so accepted: true + still-listed is indistinguishable from Hosted relay ghost workflow cannot be deleted #3087's "scheduler keeps running it" report without the trigger probe.

Happy to share the workflow ID, delete event IDs, and timestamps privately with a maintainer if useful. Looking forward to #3392.

[bonpiedlaroute]

Thanks for the corroboration — the trigger-probe detail is what makes this
diagnosable from outside, and it matches the code path exactly.

On your two knock-on effects, scoping honestly:

1. Resurrection on edit (relay: workflow a-tag deletion leaves current kind:30620 event live — ghost workflows in Desktop list, silent resurrection on edit #2390). Tombstoning the definition removes the
   ghost from workflows list, so the edit trap is no longer reachable through
   the normal flow. But it does not change handle_workflow_def's
   "unknown id ⇒ create" semantics — a client holding a stale id can still
   re-create. fix(workflow): stop deleted workflows from returning after a stale edit #2489 covers more of this than my fix(relay): retire the kind:30620 event on workflow delete (#2879) #3392 does.

2. Hosted relay ghost workflow cannot be deleted #3087's "scheduler keeps running it". I don't think either PR fixes that.
   invalidate_channel_workflows is an in-process cache invalidation
   (crates/buzz-workflow/src/lib.rs:131), so on a multi-pod hosted relay only
   the pod that handled the deletion drops its cached copy. Another pod's
   scheduler would keep firing from a stale entry. I have not traced the
   scheduler's read path to confirm, so treat that as a hypothesis grounded in
   the cache code rather than a verified finding — but it would explain
   accepted: true + a workflow that still runs on a hosted community, which
   the event-tombstone fix alone cannot.

Happy to file that separately if a maintainer confirms the read path.