fix(flow): activate schedules via Scheduler Service (#479, 0.66.1)#480
Merged
Conversation
flow schedule only wrote the keboola.scheduler Storage config, so the
schedule showed enabled but the cron trigger never fired until re-saved
in the UI. Register the config with the Scheduler Service after the
upsert (POST /schedules) and deregister it in schedule-remove
(DELETE /configurations/{id}) before deleting the config. Activation
failure is non-fatal: the config stays written, the result carries
activated=false plus a warning, and the exit code stays 0.
Deduplicate the scheduler-config target matching used by list_flow_schedules, set_flow_schedule, and remove_flow_schedule into _schedules_targeting_flow, skip SchedulerClient construction in remove_flow_schedule when no schedule targets the flow, and trim scheduler_client docstrings to match sibling clients.
natocTo
force-pushed
the
fix/flow-schedule-scheduler-activation
branch
from
a00df6d to
096dcdc
Compare
Say 'deactivated' instead of 'activated' in the success line when --disabled was used, and soften the activation-failure warning: a previously registered schedule may keep running with its old state, so the service 'may not reflect the updated configuration' rather than 'will NOT fire'.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
set_flow_schedule only caught KeboolaApiError around scheduler.activate_schedule(), so a non-API failure (e.g. json.JSONDecodeError from a malformed 2xx response body) would crash the command even though the Storage config was already written successfully -- breaking the documented "activation failure is non-fatal" contract. Mirrors the existing broad-catch pattern in _fetch_flow_schema for the same reason.
ZdenekSrotyr
approved these changes
Jul 15, 2026
ZdenekSrotyr
left a comment
ZdenekSrotyr
left a comment
Contributor
There was a problem hiding this comment.
Now it looks good, thank you!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket: https://linear.app/keboola/issue/AJDA-3000/support-16939-flow-schedule-fail-after-migration
Why
Closes #479.
kbagent flow scheduleonly wrote thekeboola.schedulerStorage configuration and never called the Scheduler Service, so the schedule showedstate: enabledbut the cron trigger never fired until the schedule was re-saved in the UI.flow schedule-removehad the mirror problem: it deleted the Storage config but left the service-side registration behind. The failure was silent — the command reported success.What changed
flow schedulenow registers the config with the Scheduler Service (POST /schedules) after the upsert — also for--disabled, which deregisters the trigger. The result carriesactivated: true/falseandwarnings.Warning: ...; JSON:warningsarray), exit code stays 0.flow schedule-removederegisters each schedule from the service (DELETE /configurations/{id}, 404 tolerated) before deleting its Storage config.flow_service.py,schedule_service.py,AGENT_CONTEXT).Layers
scheduler_client.py—SchedulerClient(BaseHttpClient), URL derivedconnection.→scheduler., authX-StorageApi-Token, methodsactivate_schedule/remove_schedule. Modeled onai_client.py.FlowServicegains an injectedscheduler_client_factory(same DI pattern asai_client_factory);set_flow_schedule/remove_flow_schedulecall the service after/before the Storage writes.commands/flow.pyprints activation state and warnings; no signature changes.permissions.py/server/routers/ SKILL.md table changes (routes call the same service and inherit the fix).Tests & docs
tests/test_scheduler_client.py(pytest-httpx: URL derivation, request envelopes, auth header, 403/404 mapping).test_flow_service.py: activation after create AND update,--disabledstill calls the service, 403 →activated: false+ warning without raising, remove deregisters beforedelete_config, 404 tolerated, other failures warn but don't block.test_flow_cli.py: warnings in human + JSON output, exit stays 0.make checkgreen: 4236 passed, lint/format/ty/command-sync/error-codes clean.changelog.py(0.66.1),CLAUDE.md,AGENT_CONTEXT,commands-reference.md,gotchas.md(since v0.66.1entry incl. the 'schedules created by older versions stay dormant' migration note),keboola-expert.md§3 gotcha + VERSION GATE.Verification (real stack)
Manual smoke test against a dev project on
connection.north-europe.azure.keboola.com:flow schedule --cron '0 6 * * *'→activated: true;GET {scheduler_url}/schedulesconfirmed the registration exists on the service (previously it did not, which is exactly the bug).flow schedule-remove --yes→ config deleted ANDGET /schedulesshows the registration is gone.self-review skipped: kbagent Claude Code plugin not installed in this environment.