Skip to content

Use Kubernetes CronJob for cron-based TaskSpawners#449

Open
axon-agent[bot] wants to merge 3 commits intomainfrom
axon-task-430
Open

Use Kubernetes CronJob for cron-based TaskSpawners#449
axon-agent[bot] wants to merge 3 commits intomainfrom
axon-task-430

Conversation

@axon-agent
Copy link

@axon-agent axon-agent bot commented Feb 26, 2026

Summary

  • Replace custom cron polling logic in TaskSpawner with native Kubernetes CronJob scheduling
  • When spec.when.cron is set, the controller now creates a CronJob (not a Deployment) that runs the spawner in one-shot mode on the cron schedule itself
  • This eliminates the confusing pollInterval + cron schedule overlap (closes Re implement TaskSpawnwer's cron #430, related to having pollinterval and cron doesn't make sense #138)
  • Add --one-shot flag to the spawner binary for single-cycle execution used by CronJob pods
  • Add status.cronJobName field to track the CronJob resource
  • Add tests for CronJob building, schedule updates, suspend toggle, and stale resource cleanup
  • Clean up stale Deployment/CronJob when switching between polling and cron modes to prevent duplicate task spawning

Test plan

  • make verify passes
  • make test passes (all unit tests including new stale resource cleanup tests)
  • CI e2e tests pass
  • Manual testing: create a TaskSpawner with when.cron and verify CronJob is created
  • Manual testing: verify suspend/resume toggles CronJob .spec.suspend
  • Manual testing: verify schedule updates propagate to CronJob
  • Manual testing: switch a TaskSpawner from polling to cron and verify old Deployment is cleaned up

🤖 Generated with Claude Code

Copy link

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 10 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/taskspawner_controller.go">

<violation number="1" location="internal/controller/taskspawner_controller.go:91">
P2: Cron-based reconciliation doesn’t clean up an existing Deployment when a TaskSpawner is switched from polling to cron, so the old Deployment keeps running and can spawn duplicate tasks. Add a cleanup step before creating/updating the CronJob.</violation>
</file>

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.

gjkim42 and others added 3 commits February 26, 2026 19:25
Replace the custom cron polling logic with native Kubernetes CronJob
scheduling. Previously, cron-based TaskSpawners ran a long-lived
Deployment that polled on pollInterval and computed missed cron ticks.
This was confusing because pollInterval and cron schedule served
overlapping purposes (issue #138).

Now, when spec.when.cron is set, the controller creates a CronJob
instead of a Deployment. The CronJob runs on the cron schedule itself,
executing the spawner binary in one-shot mode (--one-shot flag) which
runs a single discovery cycle and exits. This eliminates the need for
pollInterval for cron use cases and delegates scheduling to Kubernetes.

Key changes:
- Add --one-shot flag to axon-spawner binary for single-cycle execution
- Add BuildCronJob method to DeploymentBuilder for creating CronJobs
- Split controller reconciliation into reconcileDeployment (GitHub/Jira)
  and reconcileCronJob (cron) paths
- Add status.cronJobName field to TaskSpawnerStatus
- Add RBAC for batch/cronjobs and watch CronJobs in SetupWithManager
- Add tests for CronJob builder, schedule updates, and suspend toggle

Closes #430
Related: #138

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Copy p.args before appending --one-shot to avoid mutating the shared
  backing array from buildPodParts
- Rename TestCronJobReconciliation_Create to TestIsCronBased since that
  is what the test actually verifies

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When a TaskSpawner switches from polling-based (Deployment) to cron-based
(CronJob) or vice versa, delete the old resource before creating the new
one. Without this cleanup, the old Deployment/CronJob would keep running
alongside the new resource, potentially spawning duplicate tasks.

Add deleteStaleResource helper and tests for both switch directions.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Re implement TaskSpawnwer's cron

1 participant