cron: durable controls and stable occurrence replay - #19
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThe cron package adds in-place job updates, request correlation IDs, persistence-status responses, scheduler-owned delivery envelopes, deterministic retry metadata, and claimed-occurrence preservation during crash recovery. Documentation and tests cover the new protocol and behavior. ChangesCron scheduler changes
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant CronScheduler
participant GenswarmsCron
participant CronStore
participant Sink
CronScheduler->>GenswarmsCron: recover or dispatch claimed occurrence
GenswarmsCron->>CronStore: load claimed_due and job state
CronStore-->>GenswarmsCron: persisted job state
GenswarmsCron->>Sink: deliver cron envelope
Sink-->>GenswarmsCron: delivery result
GenswarmsCron->>Sink: retry with same fire_id and next attempt
Possibly related PRs
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Released as |
What changed
Why
Product-owned recurring workflows need cron to remain a timing primitive while still knowing whether a scheduler control was accepted durably. They also need one logical occurrence id to survive retries and a scheduler crash.
Safety
Targets, payloads, origin, creator, and dedupe keys remain immutable during updates. Request ids add no authority. A retained delete tombstone is terminal and non-runnable.
Validation
./checks/run.shSummary by CodeRabbit
New Features
Bug Fixes
Documentation