feat(cron): add immediate config to control the behaviour on start#461
Conversation
📝 WalkthroughWalkthroughThis PR adds a new ChangesCron Immediate Startup Trigger
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Comment |
Greptile SummaryThis PR adds an
Confidence Score: 5/5Safe to merge — the end-to-end wiring is complete and the immediate=false anchoring logic correctly prevents the first-tick no-fire regression. The previously flagged first-tick scheduling problem is properly resolved: set_last_cron_triggered(&id, now) updates in-memory state before continue, so the next watcher tick sees a real timestamp and schedules normally. All struct fields, serialisation, CLI, TUI, and docs paths are consistently updated. No files require special attention. Important Files Changed
Reviews (2): Last reviewed commit: "feat(cron): add `immediate` config to co..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
gaojunran
force-pushed
the
feat-cron-immediate
branch
from
689fdf9 to
8ac27af
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/cli/config/add.rs`:
- Around line 123-125: The cron_immediate flag is a no-op unless cron_schedule
is provided; add validation by annotating the cron_immediate field with clap's
requires = "cron_schedule" (e.g., #[clap(long, requires = "cron_schedule")]) and
also add a defensive check in the run() function (or the impl that processes the
parsed args) to return an error or exit early if cron_immediate is true while
cron_schedule is empty, referencing the cron_immediate and cron_schedule fields
and the run() method to ensure both compile-time clap validation and a runtime
fail-fast path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 537ac398-19db-488a-9c58-65be38925a09
📒 Files selected for processing (15)
docs/cli/commands.jsondocs/cli/config/add.mddocs/guides/scheduling.mddocs/public/schema.jsondocs/reference/configuration.mdpitchfork.usage.kdlsrc/cli/config/add.rssrc/config_types.rssrc/daemon.rssrc/pitchfork_toml.rssrc/supervisor/lifecycle.rssrc/supervisor/state.rssrc/supervisor/watchers.rssrc/tui/app.rstests/test_pitchfork_toml.rs
| /// Trigger cron immediately on first check (default: false) | ||
| #[clap(long)] | ||
| cron_immediate: bool, |
There was a problem hiding this comment.
❓ Verification inconclusive
🏁 Script executed:
#!/bin/bash
# Verify that --cron-immediate currently has no declared dependency and is conditionally ignored.
rg -n -C3 'cron_immediate|cron_schedule|PitchforkTomlCron' src/cli/config/add.rsRepository: endevco/pitchfork
Length of output: 2203
🌐 Web query:
endetvco/pitchfork src/cli/config/add.rs cron_immediate cron_schedule
💡 Result:
In the context of the pitchfork CLI (endevco/pitchfork), cron_immediate and cron_schedule are related to the configuration of daemons managed by the tool. Pitchfork allows users to run daemons on a schedule using cron expressions [1]. While the specific identifiers cron_immediate and cron_schedule do not appear as top-level CLI command flags for pitchfork config add, they correspond to components of the cron configuration within the project configuration file (pitchfork.toml) [2][1]. When configuring a daemon with a cron schedule, the full form of the configuration uses a table containing a schedule field [1]: [daemons.example] run = "./script.sh" cron = { schedule = "0 0 2 * * *", retrigger = "finish" } The configuration logic within the pitchfork codebase handles how these schedules are interpreted and executed. Specifically, the supervisor component of pitchfork includes a Cron Watcher that runs at a configurable interval (defaulting to 10 seconds) to check if any cron-scheduled daemons should be triggered [3][4][5]. The retrigger modes (such as finish, always, success, and fail) define how the system behaves if a scheduled task is triggered while a previous execution is still active [1].
Citations:
- 1: https://pitchfork.en.dev/guides/scheduling.html
- 2: https://pitchfork.en.dev/cli/config/add.html
- 3: https://pitchfork.en.dev/reference/settings
- 4: https://pitchfork.en.dev/reference/settings.html
- 5: https://pitchfork.en.dev/concepts/architecture.html
🌐 Web query:
endevco/pitchfork "src/cli/config/add.rs" cron_immediate cron_schedule
💡 Result:
In the endevco/pitchfork project, cron scheduling is managed via a configuration field in the daemon definition [1]. While the specific file path src/cli/config/add.rs relates to the CLI command used to add new daemon configurations [2], the core logic for cron scheduling relies on a 'cron' field in the pitchfork.toml file [1]. This 'cron' field accepts either a cron expression string (shorthand) or an inline table (full form) containing a 'schedule' parameter [1]. The 'cron_schedule' terminology is explicitly used in the full form configuration, such as in: [daemons.backup] run = "./scripts/backup.sh" cron = { schedule = "0 0 2 * * *", retrigger = "finish" } Although you mentioned 'cron_immediate', Pitchfork's scheduling documentation primarily emphasizes recurring 'cron' expressions and 'retrigger' modes (such as 'finish', 'always', and 'success') to control daemon execution behavior [1]. The system checks for these scheduled tasks at an interval defined by the 'supervisor.cron_check_interval' setting (defaulting to 10 seconds) [3][4].
Citations:
- 1: https://pitchfork.en.dev/guides/scheduling.html
- 2: https://pitchfork.en.dev/cli/config/add.html
- 3: https://pitchfork.en.dev/reference/settings.html
- 4: https://pitchfork.en.dev/concepts/architecture.html
🌐 Web query:
raw.githubusercontent.com endevco pitchfork src/cli/config/add.rs cron_immediate
💡 Result:
The query “raw.githubusercontent.com endevco pitchfork src/cli/config/add.rs cron_immediate” appears to be looking for Pitchfork source code in endevco/pitchfork (specifically src/cli/config/add.rs) and a symbol/flag named “cron_immediate”. Based on the authoritative sources I found, Pitchfork supports cron scheduling via the daemon configuration field cron = ... and provides cron “retrigger modes” such as finish (default), always, success, and fail (but I did not find any documentation or evidence for a config/CLI option literally named cron_immediate). In particular, the official Pitchfork cron guide describes the cron field and “Retrigger Modes” and does not mention cron_immediate as a mode or flag. [1] I also found official Pitchfork CLI documentation for pitchfork config add, including arguments --cron-schedule and --cron-retrigger, with retrigger behavior restricted to finish, always, success, and fail. This again does not mention any cron_immediate option. [2] So, with high confidence from the cited docs: there is no documented cron_immediate option in the Pitchfork configuration/CLI interface; cron behavior is controlled via --cron-schedule plus --cron-retrigger. [2][1] If you want, paste the exact raw.githubusercontent.com/... URL you expected (or the exact snippet mentioning “cron_immediate”), and I can locate the precise code path/constant for it in the repository.
Citations:
🌐 Web query:
"cron_immediate" "src/cli/config/add.rs" endevco/pitchfork
💡 Result:
The term cron_immediate does not appear to be a standard or public-facing identifier within the endevco/pitchfork project [1][2][3]. While the endevco/pitchfork CLI does provide functionality for managing cron jobs via the pitchfork config add command, its configuration options for cron are documented as --cron-schedule and --cron-retrigger [4]. It is possible that cron_immediate refers to internal source code or a specific private implementation detail within src/cli/config/add.rs that is not exposed in the public documentation or primary API [4][1]. In similar Rust-based scheduling contexts (such as zino-rs), immediate execution flags are sometimes used to run a job immediately upon initialization or scheduling [5][6], but no direct evidence links the specific string cron_immediate to the endevco/pitchfork codebase [4][1][2].
Citations:
- 1: https://github.com/endevco/pitchfork/tree/v2.3.0
- 2: https://github.com/endevco/pitchfork/tree/release-plz-2026-05-03T16-39-43Z
- 3: https://github.com/endevco/pitchfork/tree/v2.4.0
- 4: https://pitchfork.en.dev/cli/config/add.html
- 5: https://github.com/zino-rs/zino/blob/20ee3836/crates/zino-core/src/schedule/job.rs
- 6: https://github.com/zino-rs/zino/blob/20ee3836/crates/zino-core/src/schedule/async_job.rs
🌐 Web query:
"cron-immediate" endevco/pitchfork clap
💡 Result:
The term cron-immediate does not appear to be an official feature, configuration option, or command in the Pitchfork daemon manager [1][2]. Pitchfork is a tool for managing daemons, including support for cron-based scheduling [1][3]. Its documentation defines retrigger modes for cron jobs, which dictate how the supervisor handles a new scheduled run while a previous one is still active [2]. The currently supported retrigger modes are [2]: finish (default): Only triggers a new run if the previous execution has finished [2]. always: Always triggers a new run, stopping the previous one if it is still active [2]. success: Only triggers if the previous execution succeeded (exit code 0) [2]. fail: Only triggers if the previous execution failed [2]. It is possible that "cron-immediate" was a misinterpreted reference to one of these modes (such as "always," which forces execution) or a misunderstanding of how Pitchfork's CLI interface (built with clap) handles task triggering [2][4]. Pitchfork CLI commands are implemented using the Rust clap crate, and interaction with the supervisor is handled via IPC [4][5].
Citations:
- 1: https://github.com/jdx/pitchfork/blob/main/README.md
- 2: https://pitchfork.en.dev/guides/scheduling.html
- 3: https://github.com/jdx/pitchfork
- 4: https://github.com/jdx/pitchfork/blob/main/CRUSH.md
- 5: https://docs.rs/pitchfork-cli/latest/pitchfork_cli/
🌐 Web query:
"cron_immediate" "clap(" endevco/pitchfork
💡 Result:
The terms "cron_immediate" and "clap(" do not appear as a combined, functional feature within the endevco/pitchfork project [1][2][3]. Pitchfork is a CLI tool for managing daemons and recurring tasks [1][3]. While it does support cron scheduling [1][3] and uses the Rust clap library for its command-line interface [1][3], the specific string "cron_immediate" is not a recognized configuration or command parameter in the project's source code or documentation [1][4][3]. The search results indicate that "cron_immediate" is a parameter used in other software, such as the betterweb/cron Docker container [5], which allows for immediate execution of scheduled jobs. Additionally, "clap(" is a common pattern in Rust codebases when initializing the clap command-line parser [6][7], but it is not a specific identifier associated with a "cron_immediate" feature in pitchfork. If you are seeing these terms in relation to a specific codebase or configuration file, it is possible they originate from a different tool or a misinterpretation of a separate integration [5].
Citations:
- 1: https://github.com/endevco/pitchfork/tree/release-plz-2026-05-03T16-39-43Z
- 2: ee767ff
- 3: https://github.com/endevco/pitchfork/tree/v2.4.0
- 4: https://github.com/endevco/pitchfork/blob/v2.3.0/pitchfork.usage.kdl
- 5: https://hub.docker.com/r/betterweb/cron
- 6: https://docs.rs/clap/latest/clap/struct.Command.html
- 7: https://github.com/clap-rs/clap/blob/v3.0.9/examples/tutorial_derive/README.md
Require --cron-schedule when --cron-immediate is set.
Pitchfork’s cron CLI/docs describe cron configuration via --cron-schedule (and retrigger via --cron-retrigger), so if src/cli/config/add.rs exposes --cron-immediate, it should not become an unused/no-op input. Add clap validation (e.g., requires = "cron_schedule" on the argument) and/or fail fast in run() when --cron-immediate is provided without --cron-schedule.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/cli/config/add.rs` around lines 123 - 125, The cron_immediate flag is a
no-op unless cron_schedule is provided; add validation by annotating the
cron_immediate field with clap's requires = "cron_schedule" (e.g., #[clap(long,
requires = "cron_schedule")]) and also add a defensive check in the run()
function (or the impl that processes the parsed args) to return an error or exit
early if cron_immediate is true while cron_schedule is empty, referencing the
cron_immediate and cron_schedule fields and the run() method to ensure both
compile-time clap validation and a runtime fail-fast path.
2 participants
fixes #460
Summary by CodeRabbit
New Features
--cron-immediateflag andcron.immediateconfiguration option to trigger scheduled cron jobs immediately on daemon startup if scheduled within the last 10 seconds (defaults tofalse)Documentation
Tests