feat(python): manage the periodic-schedule catalog - #502
Conversation
The 4-tuple dropped queue, last_run, next_run and timezone, so a caller could not tell when a schedule next fires.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughPython periodic schedules now expose catalog listing, pause/resume/delete operations, complete schedule metadata, asynchronous wrappers, package exports, documentation, and tests. ChangesPeriodic catalog management
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@docs/content/docs/shared/guides/core/scheduling.mdx`:
- Around line 369-372: Update the scheduling guide paragraph around
`run_worker()` and `@queue.periodic()` to clarify that producer-only processes
can still list and manage schedules already persisted in the shared backend.
Qualify the empty-list statement so it applies only to schedules newly declared
by that process, which remain absent until a worker registers them.
In `@sdks/python/taskito/mixins/periodic.py`:
- Around line 13-14: Update the periodic scheduling documentation near last_run
and next_run to state that timezone is None only when omitted, while an
explicitly supplied "UTC" remains preserved; clarify that omitted timezone
values default to UTC.
In `@sdks/python/tests/core/test_periodic.py`:
- Around line 37-46: Wrap the worker startup and poll_until setup in
teardown-safe cleanup so any exception before yield still calls queue.shutdown()
and joins the worker. Preserve the existing successful fixture flow while
ensuring the worker and database handle are released when poll_until fails.
🪄 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: f021e91c-9aa7-43a8-ab39-ec1fcefd3f95
📒 Files selected for processing (10)
crates/taskito-python/src/py_queue/mod.rsdocs/content/docs/python/api-reference/queue/index.mdxdocs/content/docs/shared/guides/core/scheduling.mdxsdks/python/taskito/__init__.pysdks/python/taskito/_taskito.pyisdks/python/taskito/app.pysdks/python/taskito/async_support/mixins.pysdks/python/taskito/mixins/__init__.pysdks/python/taskito/mixins/periodic.pysdks/python/tests/core/test_periodic.py
Closes #501.
Python could declare a cron schedule with
@queue.periodic()but never manage one afterwards — no way to list, unschedule, pause, or resume. The native module already had all four; only the Python wrappers were missing.Each entry is a
PeriodicInfo—name,task_name,cron_expr,queue,enabled,last_run,next_run,timezone. Every method has ana-prefixed async form.Notable choices
Widened the binding's return.
PyQueue.list_periodicyielded(name, task_name, cron_expr, enabled)tuples, droppingqueue,last_run,next_runandtimezone— a caller could not tell when a schedule next fires. It now emits dicts covering the whole row (thedead_letterspattern), decoded into a frozenPeriodicInfo. No Python caller consumed the tuple form, so nothing breaks.Dedicated
mixins/periodic.pyrather than splitting reads intoinspection.pyand writes intooperations.py, mirroringmixins/pubsub.py, which co-locates itsTopicMessageview with the mixin owning that concern.Catalog vs. declaration.
@queue.periodic()only declares a schedule;run_worker()is what writes it to storage. These methods act on storage, so a schedule outlives the decorator that created it — the docs now state that a producer-only process sees an empty list, and that retiring a schedule meansdelete_periodic(), not deleting the decorator. That last warning already existed; it now has a remedy attached.Docs
The "Managing periodic tasks" section of the scheduling guide carried a Python block saying no such API existed. Replaced with real usage matching the sibling blocks, plus a periodic-catalog table in the Python queue API reference.
Verification
cargo clippy -p taskito-python --all-targets— cleanuv run python -m pytest tests/— 1292 passed, 7 skipped; 5 new tests cover field population, pause/resume, delete, unknown names, and the async wrappersruff check(source + tests) ·ruff format --check·mypy taskito/— cleanpnpm --dir docs build— cleanOut of scope
PyQueue.register_periodicstill hardcodesenabled: true, so Python cannot register a schedule pre-paused the way the other shells can. Separate gap, left alone.Summary by CodeRabbit
list_periodic()now returns periodic entries with full schedule metadata (name, task, cron, queue, enabled state, last/next run, and timezone).PeriodicInfotype for public use.