update_chore crashes (500) when frequency is set; completion_criteria rejected (400) on fresh chore

[deejaywoody]

Environment:

• ChoreOps version: 1.5.1-beta.1
• Home Assistant: 2026.7.1
• This install was migrated from the original KidsChores integration to ChoreOps (not a fresh install) -- may be relevant to Bug 3 below.

Bug 1: choreops.update_chore crashes with 500 whenever frequency is included

Reproducible on a brand-new chore, so it is not data-specific:

service: choreops.update_chore
data:
  id: <any valid chore id>
  frequency: weekly

Result: 500 Internal Server Error every time, regardless of target chore age or prior state. Traceback points into services.py, handle_update_chore (line ~1658 on this build). Confirmed via HA error_log -- the request never completes.

Bug 2: completion_criteria: shared_all rejected with 400 on update

service: choreops.update_chore
data:
  id: <chore created via choreops.create_chore with no completion_criteria specified, defaults to "independent">
  completion_criteria: shared_all

Result: 400 Bad Request. Same value (shared_all) is valid and already present on other pre-existing chores in the same install, so it is not an invalid-enum issue -- something about changing it post-creation via the service is rejected.

Bug 3 (unconfirmed root cause): two specific pre-existing chores crashed on any update_chore call

Before working around it by deleting/recreating, two chores ("Sweep Stairs (Up)" and "Sweep Stairs (Dn)", both weekly/shared_all, created prior to this beta -- likely originally created back when this install was still running the KidsChores integration, before migrating to ChoreOps) returned 500 on update_chore even for a minimal points-only payload -- tried both by name and by internal id, all four attempts crashed identically. A third chore (created more recently, after the ChoreOps migration) updated with the same minimal payload succeeded normally.

Given this install has migration history from KidsChores, my suspicion is that these two chore records retained some legacy field/shape from the old KidsChores data schema that the new ChoreOps update_chore path does not handle cleanly, while chores created natively under ChoreOps do not have that legacy baggage. Records were deleted as a workaround before I could isolate the exact field causing it, so this is a hypothesis rather than a confirmed cause -- but it may be a useful lead for anyone else hitting this after migrating from KidsChores.

Impact: Cannot change an existing chore recurrence or shared-completion behavior via the update_chore service at all on this build -- only new chores can have these set, and only at creation time, not via post-creation update. Also cannot reliably update any field on chores that pre-date a KidsChores-to-ChoreOps migration, if Bug 3's hypothesis is correct.

[ccpk1]

I'm going through these sequentially so starting with bug 1, this is working OK for me.

action: choreops.update_chore
data:
name: test notification link
frequency: weekly
due_date: "2026-07-16 11:00:00"

The two things that stand out to me in your issue above are:

• Your yaml shows service: instead of action: as I would expect to see if you are calling it from the developer tools. (Maybe you are calling from somewhere else, so this might not be anything)
• In all your examples, you are referencing the chore by id: instead of the more friendly name:. id should work fine, but you would need to dig in to find it as it is the internal id of that chore looking something like id: 494ea270-e326-4e94-ad34-2271f18f93df

[ccpk1]

Consider my comments about id: in bug 1, but otherwise.

Bug 2 - At this point in time, completion_criteria can only be set on chore creation. If you look at the supported fields, you'll notice it is not shown as a valid field in chore updates. This could be changed in the future, but since completion criteria is one of the primary drivers of how a chore works, there are some underlying structure changes that have to occur when changing types, so I excluded due to complexity for the time being.

I believe this can actually be done via the UI chore edit options, but is one of the few places there isn't parity with the service yet.

Let me know your thoughts / findings on these. Once I hear back I'll take a closer look at bug 3. Thanks for taking the time to report these.

[deejaywoody]

Thanks for digging in! Retested per your notes:

• name: vs id: — retested using name: instead of id:, same 500 crash. Not the cause on our end.
• Actual root cause found: the crash happens when frequency is set without also including due_date in the same call. Your working example included both — when I replicate that exactly (frequency + due_date together), it succeeds every time. Omitting due_date and only sending frequency crashes 100% of the time, on both a brand-new chore and existing ones. Fixed both my affected chores this way — much appreciated.

Might be worth either documenting due_date as effectively required alongside a frequency change, or having it fail gracefully (400) instead of a 500 when omitted.

• Bug 2 — makes sense, agreed this is expected behavior given the structural complexity. No action needed on our end.

• Bug 3 — unfortunately I deleted those two legacy chores as a workaround before I had this diagnosis, so I can't re-test them now. Worth noting though: those records already had a due_date and frequency set, and even a plain points-only update (touching neither field) crashed 4/4 times — so it doesn't fully match the "missing due_date" pattern above. Might be a separate legacy-data issue from the KidsChores migration, but I no longer have a reproducible case to hand over. Feel free to deprioritize unless someone else hits it.

Thanks again for the fast turnaround on this!

[ccpk1]

Thanks for providing the feedback.

I thought there already was a soft fail setup for missing due date, but I'll have to check if there is something preventing it from working properly. It's worth noting that you can provide only chore name and frequency for an update, BUT the existing due date for that chore MUST already be a future date. If it isn't already set in the chore, then you need to provide it when you set the frequency.

[deejaywoody]

That explanation fully resolves Bug 3 as well — no longer a mystery.

The two "Sweep Stairs" chores that crashed on Bug 3 had a stored due_date of 2026-05-31, which was already ~6 weeks in the past by the time I attempted the update (mid-July). That matches your rule exactly: the existing due date wasn't a future date, so the update crashed even for a simple points-only payload, since no new due_date was supplied in that call to replace the stale one.

So Bug 1 and Bug 3 are the same root cause, not two separate issues:

Updating a chore that has frequency set to a recurring value will crash unless its stored due_date is currently in the future — if it isn't (either null, as in my Bug 1 repro, or simply stale/past, as in Bug 3), you must supply a new future due_date in that same update call.

Given that, I'd guess the "soft fail" check you mentioned is likely only validating "is due_date present," not "is due_date still in the future" — which would explain why a chore with a stale-but-present due date still slips through to the crash instead of getting caught early.

Thanks again for chasing this down — this closes the loop nicely on my end.