bug: task update silently discards --due when combined with --priority

[tardio-clockero]

Summary

td task update --due <string> --priority <p> silently discards the due change. The command reports success, priority is applied, and the recurrence is left untouched. Running --due on its own works.

This bites hardest on recurring tasks: a payment task that should fire on the 1st and the 15th silently stays monthly, and nothing in the output says so.

Reproduction

TID=$(td task add "repro" --project Inbox --due "every 1 months" -q)

# works
td task update id:$TID --due "every 1st, 15th"
# server: every 1st, 15th   ✅

td task update id:$TID --due "every 1 months"

# silently dropped
td task update id:$TID --due "every 2nd, 16th" --priority p1
# CLI: "Updated: repro (id:...)"
# server: every 1 months, priority 4   ❌

Only --priority triggers it. Same task, same --due value, other flags:

Combined with	Result
--priority p2	due discarded
--labels compra	applied
--content "..."	applied
--assignee me	applied
(nothing)	applied

Root cause is the API, not the CLI

src/commands/task/update.ts maps both fields correctly — it sets args.dueString and args.priority independently. The drop happens server-side. Same behaviour straight against the REST endpoint, no CLI involved:

curl -X POST "https://api.todoist.com/api/v1/tasks/$TID" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"due_string":"every 5th, 19th","priority":3}'
# HTTP 200
# GET afterwards -> due: "every 1 months", priority: 3

due_string is ignored whenever priority is present in the same payload. No error, no warning, HTTP 200.

Filing it here since the CLI is the surface where users meet it and Doist maintains both — happy to move it if there's a better venue for the API side.

Suggested handling in the CLI

Whatever happens upstream, the CLI shouldn't report success for a change it didn't make. Two options:

1. Split the request — send the priority patch and the due patch as two calls when both flags are present. Invisible to the user, fixes it today.
2. Verify and warn — compare the returned due against what was requested and surface a warning when they differ.

Option 1 keeps the command honest with no new output. I'm happy to open a PR for it if you'd take that approach.

Environment

• td 3.1.4
• @doist/todoist-sdk 13.0.0
• API v1, macOS

[gnapse]

Thanks for the detailed report.

I'm going to close this issue because it is not a CLI issue. If anything, it should be something that we fix in the Todoist backend. However, we tried the exact reproduction against production today using both:

• A locally built td v3.1.4
• Direct requests to POST /api/v1/tasks/{id}, bypassing the CLI and SDK

In both cases, the combined update applied the new recurrence and priority correctly, so we haven’t been able to reproduce the issue.

Could you confirm whether it still reproduces for you? If so, the following would help us investigate:

• The exact UTC timestamp of a failed request
• Whether it also happens with a newly created Inbox task
• Redacted task JSON before and after the update
• The update response body and any request/correlation ID from its headers
• Your Todoist language and timezone

If we can find a way to confirm that this is indeed happening at the API level, I'll handle it internally for us at Todoist to fix the backend API instead of introducing a workaround in the CLI.

[tardio-clockero]

You're right, and I owe you a correction: I cannot reproduce the --due + --priority claim, and my original methodology was flawed. Closing was the right call.

Clean re-test just now — fresh Inbox task, single combined request, 20 s of quiet before it, verified by a follow-up GET:

2026-08-07T18:07:23Z  POST {"due_string":"every 2nd, 16th","priority":4}  → HTTP 200
                      GET → due "every 2nd, 16th", priority 4   ✅

Two independent trials, both correct. Account: lang: es, tz: America/Asuncion (GMT-03:00), td 3.1.4.

What I think actually happened. My repro loop reset the due and then re-set it about 2 s later, so every "test" was two writes in quick succession. Under that hammering the API starts returning error_code: 42 with a retry_after — I hit it again today while re-testing:

{"error":"Invalid date format","error_code":42,
 "error_extra":{"event_id":"153e915af55e428ab703c1b3a80fbf65","retry_after":18},
 "error_tag":"BAD_REQUEST","http_code":400}

The --priority combination happened to be first in my matrix, so it absorbed the throttling and the other flags — tested seconds later — looked fine by comparison. I read a rate limit as a field-specific bug. Sorry for the noise.

---

A separate finding that does reproduce cleanly

While re-testing I found something narrower and, I think, real. A Spanish due_string expressing multiple days of the month is silently ignored: HTTP 200, no error, due unchanged.

Fresh Inbox task starting at every 1 months, one request at a time, 15–20 s apart, each verified by a follow-up GET:

due_string	HTTP	Resulting due.string
cada día 1 y 15	200	every 1 months	❌ silently unchanged
cada día 1, 15	200	every 1 months	❌ silently unchanged
cada 15 dias	200	cada 15 dias	✅
every 1st, 15th	200	every 1st, 15th	✅

So Spanish parsing works in general — cada 15 dias is fine — but this particular multi-day-of-month pattern is dropped, while its English equivalent on the same task succeeds. Adding "due_lang": "es" explicitly makes no difference.

The failure mode is what makes it worth a look: HTTP 200 with no error and the old value retained. A caller has no way to tell the update didn't take without issuing a second GET. That's how it bit me in real use — a recurring payment task that should fire on the 1st and the 15th silently stayed monthly.

Reproduction:

TID=$(td task add "repro" --project Inbox --due "every 1 months" -q)
sleep 20
printf '%s' '{"due_string":"cada día 1 y 15"}' > body.json
curl -s -X POST "https://api.todoist.com/api/v1/tasks/$TID" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  --data-binary @body.json -w '\n%{http_code}\n'
sleep 5
curl -s "https://api.todoist.com/api/v1/tasks/$TID" -H "Authorization: Bearer $TOKEN" | jq .due

Happy to open this as its own issue if it's useful, or drop it if the Spanish parser simply doesn't support that construction — in which case a 400 instead of a silent 200 would already be a big improvement.

[gnapse]

I retested this against current production with a freshly created task and explicit "due_lang":"es". cada día 1 y 15 returned 200 and updated the recurrence to the normalized cada día 1, 15; I couldn’t reproduce the 200/no-op behavior.

Account language is used when due_lang is omitted, but explicit "due_lang":"es" should remove that variable.

I did find that parsing depends on the task’s existing due.date: when the current occurrence is on the 15th, both Spanish forms currently fail, although the API returns 400 rather than silently succeeding. Could you share the complete due object before the request, the POST response body, and confirm whether each test case used a separate fresh task?