bug: complete/cancel silently no-op on repeating to-dos (Things rejects the update; CLI reports success)

[ryanlewis]

Summary

things cancel <uuid> exits 0 and prints nothing, but the task's status stays open. Seen on two specific long-lived tasks; things complete on the same UUIDs works, so it is not the Things URLs auth-token path.

things edit <uuid> --cancel behaves identically — silent exit 0, no state change.

Version

things 0.5.2 (commit 87c9bca742a698c5ef5ca4cf5f779e525f7b9d0a, built 2026-08-09T00:44:11Z)

Observed

Observed with two tasks in the same project (for my own notes: "AFC"), start: 2 (Someday), tagged Work, both created 2026-04-23:

$ things cancel W1gBDJPFpwUQrdP5Am5K7J
$ echo $?
0
$ things show W1gBDJPFpwUQrdP5Am5K7J -j | jq -r .status
open

Repeated three times over several minutes, and via things edit <uuid> --cancel. Always exit 0, always still open. things complete on the same UUID transitions to completed immediately.

Not reproducible on fresh tasks

I could not trigger it with newly created tasks. All of these cancelled correctly:

Repro task	project	when	tags	result
zz-cancel-repro	—	—	—	cancelled
zz-repro-someday-noproj	—	someday	—	cancelled
zz-repro-someday-proj	<project>	someday	—	cancelled
zz-repro-anytime-proj	<project>	anytime	—	cancelled
zz-repro-tagged	<project>	someday	Work	cancelled

So project membership, Someday bucket, and tags are each ruled out individually.

Diff between a failing and a working task

Only material differences are tags and a non-zero index / todayIndex:

FAILING                             WORKING
"start": 2                          "start": 2
"startBucket": 0                    "startBucket": 0
"tags": ["Work"]                    (none)
"index": -127                       "index": 0
"todayIndex": -836                  "todayIndex": 0
"creationDate": 2026-04-23          "creationDate": 2026-08-10

The tagged repro row above shows tags alone isn't sufficient. That leaves the non-zero todayIndex on an old task as the remaining suspect — possibly a task that has previously been in Today and carries state the cancel payload doesn't account for.

Why it's silent

Almost certainly the same root cause as #19: the URL scheme gives us no callback, so a rejected update is indistinguishable from a successful one and we report exit 0 either way. Even without a fix for the cancel itself, cancel should not claim success it cannot verify — a post-write read-back and a non-zero exit on unchanged status would surface this class of failure.

Suggested

1. Read back status after cancel / edit --cancel and exit non-zero with a clear message if unchanged.
2. Work out why the update payload is rejected for these tasks — compare the emitted URL for a failing vs working UUID.

[ryanlewis]

Correcting the scope of this — it is not specific to cancel, and it is not a "some old tasks reject writes" problem either. On the same two tasks:

Operation	Result
things edit <uuid> --title "..."	lands — new title reads back immediately
things complete <uuid>	silent no-op, exit 0, stays open
things cancel <uuid>	silent no-op, exit 0, stays open
things edit <uuid> --cancel	silent no-op, exit 0, stays open
things edit <uuid> --add-tags zztest	silent no-op, tags unchanged (1 sample)

So the URL-scheme write path is reaching Things and being honoured for title, while status transitions are silently dropped for these specific tasks. Fresh tasks transition fine (see the repro table above), so it is per-task state, not a broken code path.

Both affected tasks were created 2026-04-23 and carry a non-zero todayIndex (-836, -127 index) despite sitting in Someday (start: 2) — i.e. they have previously been scheduled into Today. That inconsistent bucket/index state is my best remaining suspect.

Retitling the issue accordingly: the headline defect is that status-changing writes report success they never verified. The read-back-and-exit-non-zero fix in point 1 above is the important part regardless of the root cause — I hit this while scripting a bulk tidy-up and it silently reported two tasks closed that were still open.

[ryanlewis]

Root cause — this is a documented Things restriction, not per-task corruption

Both affected to-dos are repeating to-dos. The JSON URL scheme docs state plainly that on repeating to-dos the following attributes cannot be updated:

• when
• deadline
• completed
• canceled
• completion-date

(Same restriction applies to repeating projects.)

That accounts for every observation in this issue, and supersedes the todayIndex speculation above:

Observation	Explanation
edit --title lands	title is not a restricted attribute
complete silently no-ops	completed is rejected on repeating to-dos
cancel / edit --cancel silently no-op	canceled is rejected on repeating to-dos
Fresh repro tasks transition fine	none of them were repeating
Non-zero todayIndex on the affected tasks	incidental — a recurrence has previously passed through Today

Also worth checking against the same doc list: edit --when and edit --deadline will silently fail on repeating to-dos for the same reason. I hit --add-tags failing once on a repeating to-do too, which is not in the documented restriction list — worth a separate look, and I only have one sample.

Revised suggestion

The silent-success problem is the real defect, and it is now clearly fixable without guesswork:

1. Detect repeating to-dos and fail loudly. When the target is a repeating to-do and the requested change touches completed / canceled / when / deadline, refuse up front with an explanatory error and a non-zero exit, rather than emitting an update that Things will drop. Ideally name the restriction and point at the docs.
2. Read back and verify after any status write — the general safety net. Exit non-zero if the status did not change. This catches this class of failure and any future undocumented restriction.
3. Consider surfacing repetition in show / list -j output (e.g. an isRepeating field), since right now there is no way for a caller to know a to-do is repeating and therefore partly immutable.

Point 3 is what made this hard to diagnose from the outside: nothing in things show or the JSON indicated these two to-dos were repeating.