Relationships
#2104 Trigger schedule overrides require a swamp serve restart to take effect
Opened by svendowideit · 9/10/2026· Shipped 9/14/2026
Summary
Setting a workflow trigger override via swamp workflow trigger set does not take effect on a running swamp serve instance until it is restarted.
Context
The workflow docs state that built-in trigger.schedule changes are picked up by a filesystem watcher without restart:
A filesystem watcher monitors for changes — adding, modifying, or removing a schedule takes effect without restart.
However, trigger overrides (written to .swamp/serve.yaml via swamp workflow trigger set) are documented separately as:
Overrides are read at startup — the running serve instance must be restarted for changes to take effect.
Problem
This is an inconsistent and surprising UX. A user who changes a schedule with swamp workflow trigger set expects it to apply immediately (as built-in schedule edits do), but instead must manually restart swamp serve. There is no warning or hint from the trigger set command that a restart is required.
Steps to reproduce
- Start
swamp serve. - Run
swamp workflow trigger set <workflow> --schedule "0 */2 * * *". - Observe the effective schedule via
swamp workflow trigger get <workflow>(shows the new override). - Check the running serve instance's registered cron /
/healthnext-fire times — they still reflect the old schedule until restart.
Expected behavior
Trigger overrides should be picked up by the running serve instance without a restart (consistent with built-in schedule edits), or at minimum swamp workflow trigger set should warn that a restart is required.
Environment
- swamp 20260910.194957.0-sha.ae1ed149
Shipped
Click a lifecycle step above to view its details.
svendowideit commented 9/10/2026, 11:32:50 PM
I guess the only substance i'd have added is that I also expected the swamp serve log output to mention the change, as it mentions the trigger times on restart
svendowideit commented 9/10/2026, 11:34:05 PM
currently running as daemon:
^Csven@xeon:~systemctl --user status swamp-serve
● swamp-serve.service - Swamp serve daemon
Loaded: loaded (/home/sven/.config/systemd/user/swamp-serve.service; enabled; preset: enabled)
Drop-In: /home/sven/.config/systemd/user/swamp-serve.service.d
└─override.conf
Active: active (running) since Fri 2026-09-11 09:19:27 AEST; 13min ago
Invocation: 439d77e6b8bf48f7a617f759cc02a692
Main PID: 11206 (swamp)
Tasks: 7 (limit: 34813)
Memory: 151.9M (peak: 194.4M)
CPU: 41.891s
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/swamp-serve.service
└─11206 /home/sven/.local/bin/swamp serve --repo-dir /home/sven/src/swamp-club --port 9090 --host 127.0.0.1
Sep 11 09:19:29 xeon swamp[11206]: system │ Registered schedule for workflow "@svendowideit/news-fusion": "0 */12 * * *"
Sep 11 09:19:29 xeon swamp[11206]: system │ Scheduled workflow "@svendowideit/news-fetch" ("0 */2 * * *")
Sep 11 09:19:29 xeon swamp[11206]: system │ Registered schedule for workflow "@svendowideit/news-fetch": "0 */2 * * *" (serve.yaml override)
Sep 11 09:19:29 xeon swamp[11206]: system │ Scheduled execution service started with 3 schedules
Sep 11 09:19:29 xeon swamp[11206]: system │ --group-refresh-interval is set but --auth-mode oauth is not configured; group refresh is disabled
Sep 11 09:19:29 xeon swamp[11206]: system │ WebSocket API server listening on "ws://127.0.0.1:9090"
Sep 11 09:19:29 xeon swamp[11206]: system │ Instance heartbeat started (id: "e0bb79de-c00b-43be-933e-13c825422891")
Sep 11 09:19:29 xeon swamp[11206]: system │ Continuous reconciliation timer started
Sep 11 09:19:29 xeon swamp[11206]: system │ Telemetry: flushing to "https://telemetry.swamp-club.com" as "d7bdc303-ea18-40fb-a534-165c88119fd7" (authenticated: true)
Sep 11 09:19:29 xeon swamp[11206]: system │ Startup complete — /ready is now serving 200stack72 commented 9/14/2026, 12:33:40 AM
Thanks @svendowideit for reporting this! We shipped: Server-side trigger set/remove handlers apply overrides to the running scheduler immediately after writing to serve.yaml, using the existing updateTriggerOverrides() method. No filesystem watching, polling, or local CLI changes.. The fix has been merged and a release is on its way. We appreciate your contribution to swamp.
Sign in to post a ripple.