fix(cron): accept bare cron-expression string in Schedule deserializer (Sentry CORE-RUST-FY)#2874
Conversation
Fixes Sentry issue CORE-RUST-FY (closes tinyhumansai#2866). The `openhuman.cron_update` RPC deserializes the `schedule` field as an internally-tagged `Schedule` enum. Agents and some frontend callers were sending a bare string like `"0 9 * * 1"` instead of the structured object `{"kind":"cron","expr":"0 9 * * 1"}`, causing serde to reject with: "invalid type: string, expected internally tagged enum Schedule" Fix: add a custom `Deserialize` impl for `Schedule` that routes a bare string to `Schedule::Cron { expr, tz: None, active_hours: None }`, while still delegating the full object form to the existing tagged-enum logic. Serialization is unchanged (always emits the object form). New tests: - `schedule_deserializes_bare_cron_string` - `schedule_deserializes_bare_5_field_cron_string` - `cron_job_patch_accepts_bare_schedule_string` (the exact failing shape) - `cron_job_patch_still_accepts_structured_schedule_object` (regression)
|
Warning Review limit reached
More reviews will be available in 13 minutes and 13 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
Summary
Rebased version of #2868 by @graycyrus on the latest
upstream/main.The original PR's branch included a cherry-picked observability commit (
fix(observability): classify Embedding API 401 Invalid-token as SessionExpired) that was independently merged tomainas PR #2869. This caused a merge conflict (mergeable_state: dirty) that blocked CI from running.This PR contains only the two cron-fix commits from #2868, cleanly applied on top of current
main:fix(cron): accept bare cron-expression string in Schedule deserializerstyle(cron): apply cargo fmt to Schedule deserializerNo functional changes from #2868. The fix and tests are identical.
Root cause (Sentry CORE-RUST-FY / #2866):
openhuman.cron_updatedeserializesscheduleas an internally-taggedScheduleenum. Agents and some frontend callers send a bare string like"0 9 * * 1"instead of{"kind":"cron","expr":"0 9 * * 1"}. Serde rejected this with:invalid type: string, expected internally tagged enum Schedule.Fix: Custom
Deserializeimpl forScheduleinsrc/openhuman/cron/types.rs. A bare string →Schedule::Cron { expr, tz: None, active_hours: None }. The full object form is handled byvisit_mapdelegating to an inner#[derive(Deserialize)]tagged enum viaMapAccessDeserializer. Serialization unchanged.Tests: 4 unit tests — bare string, 5-field
*/5,CronJobPatchwith bare string (exact failing payload), regression guard for the structured object form.Closes #2868.
Test plan
cargo test --lib openhuman::cron::types— all 20 passcargo check— clean