Workflows: fresh scheduled triggers never fire and delete returns accepted while definition persists

[Dilosaurus]

Summary

Fresh scheduled workflows are accepted and listed but never fire. Deleting the same fresh workflow returns accepted:true, yet the workflow remains listed and active-looking.

This is a silent-success failure in both directions: create/delete report success while the requested scheduler/delete side effect does not happen.

This is not limited to legacy pre-#1369 orphan rows described in #1593. The reproduction below used a newly created workflow on the current hosted relay/runtime.

Reproduction 1 (2026-08-03 UTC)

Two fresh schedule probes were created with accepted:true in a quiet test channel:

cron "53 15 * * *"  -> no message by 15:56 (4.5 minutes past the due time)
cron "* * * * *"    -> no messages by 16:00 (about four due slots)

The every-minute probe removes timezone interpretation as an explanation. Neither fresh definition fired.

Reproduction 2 (2026-08-04/05 UTC)

Created fresh workflow 7ff24431-aef7-40a6-b3a3-8c5af812e44d at 2026-08-04T23:54:19Z:

name: step0-fresh-cron-canary
description: Fresh five-minute scheduler verification
trigger:
  on: schedule
  cron: "*/5 * * * *"
steps:
  - id: canary_fire
    action: send_message
    text: "CANARY CRON FIRE <unique-token>"

Observed:

• Watched for 14+ minutes (at least two due five-minute slots): zero token-bearing messages.
• Re-read channel history through 2026-08-05T15:23:42Z: zero token hits.
• Ran buzz workflows delete --workflow 7ff24431-aef7-40a6-b3a3-8c5af812e44d.
• CLI output:

{"accepted":true,"event_id":"625d11e16eab912875593a6398bfa25a61b1c892c609404f2a3c0139a1d4e6f1","message":""}

• An immediate buzz workflows list still returned both 7ff24431… and an unrelated workflow.
• Rechecked immediately before filing: 7ff24431-aef7-40a6-b3a3-8c5af812e44d still appears in workflows list with the original YAML.

Expected behavior

• A fresh scheduled workflow fires on due cron ticks.
• Deletion either removes the definition and scheduler row or returns a non-success outcome explaining why it did not.
• accepted:true should not be the only signal when the server-side side effect fails.

Actual behavior

• Definition create is accepted and visible, but scheduled action never runs.
• Delete is accepted, but the definition persists.
• No error is surfaced to the caller.

Impact

Scheduled safety checks and agent wakeups appear configured but silently never execute. Operators also cannot reliably clean up the inert definitions because delete claims success without changing state.

Suggested diagnostics/fix

1. Return a structured execution result for workflow create/delete side effects, separate from event acceptance.
2. On delete, reread the targeted workflow and fail if it still exists.
3. Log workflow ID, next due time, scheduler registration, tick, action result, and delete-row count.
4. Add an integration test that creates an every-minute workflow, observes a fire, deletes it, and proves no later fire plus absence from list/storage.

Related: #1593 covers legacy orphan rows and already notes silent-success deletion; this report demonstrates the same externally visible failure on a fresh current workflow. #4696 covers a separate Desktop workflow-list/query problem.

[Pratikkale26]

The second half of this — "delete returns accepted:true while the definition persists" — is the same bug as #4864, and #4882 has a fix open for it.

Short version: the relay's NIP-09 a-tag deletion handler dropped the workflows row that drives execution but never tombstoned the kind:30620 definition event. Every client reads workflow definitions by querying kind:30620 (buzz workflows list/get, and the desktop's get_channel_workflows), so a deleted workflow keeps being returned. Worse, publishing a new definition for the same d tag re-upserts the row from the still-live event, so workflows update resurrects it — with a freshly issued webhook secret.

That should account for the delete symptom you're seeing, including the workflow still appearing in list afterwards. Worth re-testing that half against #4882 if you're able to build from the branch.

The scheduler half looks genuinely separate — a fresh */5 * * * * definition never firing isn't explained by the deletion path, and your every-minute probe rules out timezone interpretation. Those are probably worth treating as two issues, since fixing one won't move the other.

One thing that might help narrow the scheduler side: the cron loop and the workflow definition read different sources. Execution is driven by the workflows projection table, while list reads kind:30620 events — so "listed but never fires" is consistent with the definition event existing while the projection row is missing or not picked up by the scheduler, rather than with cron parsing being wrong. Checking whether a row exists in workflows (and in scheduled_workflow_fires) for a freshly created scheduled workflow would separate those two possibilities quickly.