Re implement TaskSpawnwer's cron

[gjkim42]

TaskSpawner implemented its own cron logic.

Is it better to just create a kubernetes CronJob?

Is it better to add CronTask CRD instead of TaskSpawner with cron?

[axon-agent]

🤖 Axon Agent @gjkim42

Axon Triage Report

Kind: kind/api

Status: STILL VALID

Evidence:

• TaskSpawner's built-in cron logic exists in internal/source/cron.go and is wired through cmd/axon-spawner/main.go:369-380. It uses github.com/robfig/cron/v3 to compute ticks between LastDiscoveryTime and now, generating one Task per tick.
• No merged PRs or commits reference this issue or address replacing the cron implementation.
• The current design has a known awkwardness: cron-based TaskSpawners still use pollInterval to control how often the spawner checks for missed ticks, which is conceptually confusing (see having pollinterval and cron doesn't make sense #138).
• The three approaches raised (keep custom cron in TaskSpawner, delegate to Kubernetes CronJob, or introduce a CronTask CRD) each have trade-offs:
  • Current approach (custom cron in TaskSpawner): Unified API surface, but conflates polling and scheduling, and reimplements what Kubernetes already provides.
  • Kubernetes CronJob: Leverages native scheduling, but loses the TaskSpawner's deduplication, maxConcurrency, maxTotalTasks, and status tracking features.
  • CronTask CRD: Clean separation of concerns, but adds API surface area and another controller to maintain.

Duplicates found: #138 (directly questions the cron + pollInterval API design — same fundamental concern about whether the current cron integration in TaskSpawner makes sense)

Recommendation: KEEP OPEN — This is a valid API design discussion. Consider consolidating with #138 since both address the same underlying question about how cron scheduling should integrate with the TaskSpawner API. Issue #287 is tangentially related (cron resilience) but focuses on different aspects.