Skip to content

Expose trigger CRUD on the flow server so the dashboard can schedule flows - #55

Merged
pallaoro merged 1 commit into
mainfrom
feat/trigger-http-routes
Sep 16, 2026
Merged

pallaoro merged 1 commit into
mainfrom
feat/trigger-http-routes

Conversation

@pallaoro

Copy link
Copy Markdown
Member

Why

A cron trigger could only be created by the agent (flow_trigger tool). The dashboard's Schedule page reads OpenClaw cron only, so "New task" can only mean a message to the agent, and flow schedules were invisible until clawnify#1807 mirrored them read-only.

What

  • /flows/triggers on the local flow server: GET (list, optional ?flow=), POST (create), PATCH /:id (update; enabled:false pauses), DELETE /:id, POST /:id/run (202, detached).
  • Same validation as the tool (assertValidSchedule), plus a flow-existence check. Writes call scheduler.sync() so the change is armed immediately.
  • The server reaches the scheduler through an accessor, not a captured instance: register() re-runs on reloads and swaps the scheduler while the first server survives the activeServer guard.
  • origin: "agent" | "dashboard" on trigger records.
  • Tests: tests/serve-triggers.test.ts covers validation, arm/disarm on pause and resume, run-now recording a run, and 404s. Full suite: 225 passing.

Version 1.6.2 → 1.6.3. The hook side (CAP schedules.* flow target) and the dashboard dialog follow in clawnify.

…flows

Until now a cron trigger could only be created by the agent through the
flow_trigger tool. The dashboard's Schedule page had no way to make one,
so the two schedulers on a box looked like one, and "New task" could only
mean a message to the agent.

The flow server gains /flows/triggers: list, create, update (pause via
enabled:false), delete, and run-now. Every write goes through the same
validation the tool uses (assertValidSchedule) plus a flow-existence check,
and arms the scheduler immediately. The server reaches the scheduler
through an accessor rather than a captured instance, because register()
re-runs on plugin reloads and replaces the scheduler while the first
server instance survives; a captured reference would point at a stopped
scheduler and re-arm its timers.

Trigger records carry an origin field (agent or dashboard) so the two
kinds stay tellable apart once both exist.
@pallaoro
pallaoro merged commit c2d94c7 into main Sep 16, 2026
1 check passed
@pallaoro
pallaoro deleted the feat/trigger-http-routes branch September 16, 2026 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant