Bare integers are accepted for due: and wait:, but cause issues later

[jemorriso]

To report a bug...

• What command(s) did you run?

task add recur:daily due:10 wait:6 foobar

• What did you expect to happen?

The goal was to add a daily task that recurs at 10am.

• What actually happened?

task list hangs and thousands of tasks are created while it hangs.

• Paste the output of the task diag command.

task 3.0.2
   Platform: Darwin

Compiler
    Version: Apple LLVM 15.0.0 (clang-1500.3.9.4)
       Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64
 Compliance: C++17

Build Features
      CMake: 3.29.2
    libuuid: libuuid + uuid_unparse_lower
 Build type: Release

Configuration
       File: /Users/jerry/.taskrc (found), 1469 bytes, mode 100644
       Data: /Users/jerry/.task (found), dir, mode 40755
    Locking: Enabled
         GC: Enabled
    $EDITOR: nvim
Hooks
     System: Enabled
   Location: /Users/jerry/.task/hooks
             (-none-)

Tests
   Terminal: 252x117
       Dups: Scanned 8450 tasks for duplicate UUIDs:
             No duplicates found
 Broken ref: Scanned 8450 tasks for broken references:
             No broken references found

---

Running task delete will go through the tasks one by one and delete them but it takes forever if there are thousands of them. What would the effect be of deleting the rows in the tasks table? I didn't try this because I see there are other tables referencing that data, but could that be a 'last resort' way of recovering?

Thanks!

[djmitche]

Hm, that sounds like a bug in the recurrence! I've never used bare integers for due or wait - do those always parse as hours of the day?

As for recovering from this -- deleting the tasks without deleting the corresponding operations will leave your DB inconsistent, which will cause issues later. One option may be task export, filtering with a text editor, and task import?

[jemorriso]

Hi, so if you run task add foobar due:10, it will fail silently, and then when you do task list you get "'10' is not a valid date in the '' format".

So I think for some reason this error is causing the recurrence to attempt to add the task over and over again. I did try a task export but all it did was print an open bracket to the json file.

I was able to get out of this by doing task undo a number of times until task list doesn't hang.

[jemorriso]

Also, using the bare integer was just a newbie error, I did task add recur:daily due:10:00 wait:6:00 foobar and everything worked fine

[djmitche]

Hm, sounds like we have a validation issue on date/time properties, then, where we accept bare integers but then later complain about them.

[mukesh4iitb]

I have an extended question on this and looking forward to your opinion on this.

I am trying to schedule a task for habit, which should follow the following: 1- It should schedule daily with a due date 11:59 PM 2- When the due date is over, it should not been shown. However, it should be included in not completed while analyzing burndown chart.

I have tried several methods but the problem, the task repeated with -negative due date. Since, it is for habit, when due date is gone, it should be gone. No, need to show due date with negative due date.

Could you all please share your opinion, how to accomplish this task??

thanks

[felixschurk]

Hei, I am not sure about the second part of your requirements, however for the first one you could use the until property, see Using Dates Effectively. So you could use a command like this

task add \
 recur:daily \
 due:23:59 \
 wait:6:00 \
 until:due \
 foobar

I just do not know how it will pop up in the burndown chart. As far as I know, deleted tasks are not shown in there.

[ditsuke]

This is not just an issue with recurrence. It is reproducible on regular tasks, at least when modifying them.

[djmitche]

Can you give an example?

[ditsuke]

Can you give an example?

❯ task 1 mod due:2
Modifying task 1 'a'.
Modified 1 task.

❯ task
'2' is not a valid date in the '' format.

[Bckempa]

Just hit the same non-recurrence form of this as @ditsuke when I started with due:YYY-MM-DD and truncated it to the year to see if it would take it. Now running the default report complains '2025' is not a valid date in the '' format.

[djmitche]

https://gothenburgbitfactory.org/taskchampion/tasks.html#validity says that any task is valid, so I think the fix here is for the date-parsing to be more lenient when it finds this weird date format.

It's not even that weird. https://gothenburgbitfactory.org/taskchampion/tasks.html#value-representations says dates are stored as UNIX timestamps, and 2 is a valid UNIX timestamp (2 seconds past UTC midnight, January 1, 1970).

[felixschurk]

Just hit the same non-recurrence form of this as @ditsuke when I started with due:YYY-MM-DD and truncated it to the year to see if it would take it. Now running the default report complains '2025' is not a valid date in the '' format.

Did you try with setting the rc.dateformat to match now your custom input? https://taskwarrior.org/docs/dates/

I never played around with that, but I could assume that there is this problem. I mean the warning says that 'year' is not valid in '' format, so maybe setting the format '' now to 'year' e.g. would do the job.

[djmitche]

Summarizing, the issue here is that it's possible to put data into a task which then causes errors when that data is later read.

The big-picture fix is, Taskwarrior should accept any data in a task and just do its best. So even if it gets a wait property of for godot it should not fail with an error. Probably it should just act as if the wait property was not set.

[fenugrec]

The big-picture fix is, Taskwarrior should accept any data in a task and just do its best. So even if it gets a wait property of for godot it should not fail with an error.

That is not how I read the docs (here https://taskwarrior.org/docs/task/#keys) :

Timestamps are stored as UNIX epoch timestamps, in the form of an integer. ... wait - indicates the time before which this task should be hidden

That seems to imply that wait should store a unix TS, as an int. Accepting something like "wait:november" is a front-end convenience but isn't the actual value stored still a timestamp ? I had tested simply with wait=1 which should be sometime in 1970, and definitely a valid timestamp, but even that caused errors.

[djmitche]

Just above that section, https://taskwarrior.org/docs/task/#validity states that every key/value map is valid, so it's incorrect for a program to fail with an error when a task does not have the expected form. My fanciful "waiting": "for godot" was just an illustration of a potential unexpected form for a property.

You're right that the stored value should be an integer, regardless of what was provided on the command line. And that is what it does in this case. And yes, it is odd that 1 is not considered valid!

✖ sofia ~/p/taskwarrior ⸨issue3618-load-metric⸩
⸩ t add foo
TASKRC override: /home/dustin/p/taskwarrior/.taskrc
Created task 1.
✖ sofia ~/p/taskwarrior ⸨issue3618-load-metric⸩
⸩ t 1 mod due:1
Modifying task 1 'foo'.
Modified 1 task.
TASKRC override: /home/dustin/p/taskwarrior/.taskrc
✖ sofia ~/p/taskwarrior ⸨issue3618-load-metric⸩
⸩ t 1
TASKRC override: /home/dustin/p/taskwarrior/.taskrc
'1' is not a valid date in the '' format.
✖ sofia ~/p/taskwarrior ⸨issue3618-load-metric⸩
⸩ sqlite3 .task/taskchampion.sqlite3 'select * from tasks'
63e1ebce-4069-47f5-8725-b88af51d5927|{"due":"1","modified":"1727871556","status":"pending","entry":"1727871554","description":"foo"}

Notably, this is only invalid for due, not for wait.