PR 19766 review

What I found

isValidCronSchedule passes allowSevenAsSunday: true, and a test row pins 0 0 * * 7 as valid. K3s and RKE2 parse this with robfig/cron/v3, whose day of week is 0-6, so it answers end of range (7) above maximum (6). K3s ignores the error from AddJob, so nothing fails visibly. On master the option only affected a hint. This PR makes it the Save gate.

I started four throwaway K3s v1.33.5 servers with --cluster-init and left them for 4 minutes:

Fix

Drop allowSevenAsSunday from isValidCronSchedule and flip the test row. Run against the matrix below, that turns all four 7 rows into blocks and changes nothing else. Adding "day of week is 0-6" to the message would help, because the shared LabeledInput hint keeps its own copy of the check and will still describe 7 as Sunday. I'd leave that hint alone, since other cron forms use it.

Limit: I ran K3s, not RKE2. RKE2 pulls in K3s's etcd package (go.mod), and Rancher passes the schedule through unchanged, but I read those rather than provisioning a node.

What I found

The description lists this as a known regression. I confirmed it and the workaround:

• @every 1m takes real snapshots on K3s (table above), and robfig/cron accepts @every, CRON_TZ= and TZ=. So these clusters are healthy.
• Editing fixture zz19766-every disables Save on load. The form has one Save button, so version upgrades and every other edit are blocked until the schedule is replaced. The message says to use a valid cron expression, which is misleading when the schedule already works on the cluster.
• Edit as YAML does get through: after the "Save Machine Configurations" prompt, Save is enabled and sends the PUT with @every 6h intact (I intercepted it).

Options

• A, what I'd do: accept @every <duration> and a CRON_TZ=/TZ= prefix in isValidCronSchedule. A prototype of this with the card 1 fix cut the matrix's disagreements from 16 to 7: the rare forms in the matrix's last row, plus an unknown timezone name. The hint under the field would still say "Invalid cron schedule", as it does on master today.
• B: keep it strict and add a release note pointing at Edit as YAML. Simpler, but it breaks a working setup to catch a broken one.

I don't know how many clusters use these forms, so the size of this is unknown. Issue 13202 (merging the cron validators) is still open and is the longer-term home for it.

• A few other schedules K3s accepts are blocked: ? in both day fields or in hour, and stray commas such as 1,,3 * * * *. They are rare, and the existing hint already calls them invalid.
• Backups disabled keeps the bad string: with an invalid schedule and Automatic Backups off, Create is enabled and the POST carries disableSnapshots: true plus the invalid schedule. Master sends the same, K3s doesn't start its cron when snapshots are disabled, and re-enabling flags the field again.
• View mode: no warning icon and no tab flag, as described. The grey "Invalid cron schedule" hint still shows, same as master.
• Tests: unit tests only. The issue carries QA/dev-automation, so you may want to ask whether an e2e is expected.