Repository navigation
bug: to-dos inside a repeating project template are not treated as repeating for writes or filters #174
Description
Found by the #171 worker (PR #173), left out because this machine's database has no repeating project to verify against.
Task.Repeatingonly looks at the row's own recurrence column, so a to-do inside a repeating project template passescheckRepeatingand--when/--deadline/--completeon it are sent and (presumably) silently dropped by Things, the class of bug bug: complete/cancel silently no-op on repeating to-dos (Things rejects the update; CLI reports success) #129/fix: refuse writes Things drops on repeating items, and verify status changes landed #143 fixed for templates themselves.things --project "<repeating project template>"returns an empty list after fix(views): hide the to-dos inside a repeating project template #173 with no explanation; a one-line note that the project is a repeating template would help.
Both need a database with a real repeating project to confirm the row layout before changing behaviour. Not blocking v0.7.0.
Activity
ryanlewis commentedon Sep 5, 2026
Verification note from the #171 work: reading the live Things database with
sqlite3 -readonly "file:$DB?immutable=1"silently ignores the WAL, so recent rows (including every repeating row on this machine) are missing with no error. Query a checkpointed daily snapshot underThingsData-M4DZA/Backups/*.thingsdatabase/main.sqliteinstead, and treat an all-zero count from the live file as suspect.ryanlewis commentedon Sep 5, 2026
Correction to the note above: a normal read-only open of the live database today (
sqlite3 -readonly, WAL included) also returns zero rows withrt1_recurrenceRule, andthings repeatingon v0.7.0 lists nothing. So the two templates in the 2026-09-03 backups were deleted since, rather than hidden by the WAL. The backups remain the only place with repeating rows to study, and this machine still has no repeating project.feat(list): say why a repeating project template lists nothing
feat(list): say why a repeating project template lists nothing (#272)
docs(release): add v0.8.0 release notes header (#275)
ryanlewis commentedon Sep 10, 2026
Part (b) is shipped in #272 and goes out in 0.8.0. Naming a repeating project template with
--projectnow prints a one-line note on stderr saying its to-dos are not listed, and stays quiet ontrash,logbookandrepeating, which keep templates and with them their contents. Under--jsonstdout is still an empty array.Part (a) is untouched, and I am leaving this issue open for it. The reason is that there is nothing on this machine to verify it against. I checked all ten daily backups from 2026-09-01 to 2026-09-10. Not one of them contains a repeating project: across all ten, zero rows of project type carry either a recurrence rule or a repeating-template pointer. Only three of the backups hold repeating rows at all, and in those the two templates are both to-dos, and both sit inside an ordinary project that does not repeat. Between them those two templates had produced 17 generated instance rows, and none of the 17 was open. So I have no example of a to-do inside a repeating project template, and I am not willing to change
Task.RepeatingorcheckRepeatingon an assumption about a row layout I have never seen.What a future measurement needs. Create a project in the app and set it to repeat, then put two to-dos inside it, one directly in the project and the other under a heading in the project, because the existing guard resolves a child's project through
COALESCE(t.project, h.project)and the heading case is the one that would slip through if the layout differs. Leave it long enough for the app to write it out, then read it with a plain read-only open, never withimmutable=1.The columns to read, on the project row and on each child row:
type,status,trashed,project,heading,start,startBucket,startDate, and whetherrt1_recurrenceRuleandrt1_repeatingTemplateare set. Part (a) turns on whether a child carries a rule or a template pointer of its own or only its parent project does. Also worth capturing: whether a second project row appears pointing back at the template, anduntrashedLeafActionsCountandopenUntrashedLeafActionsCounton both project rows, which say whether the app counts a template's children as open work.fix(repeating): treat to-dos inside a repeating project template as r…