Task missing `entry` causes assertion failure calculating urgency

[vanya-robertson]

To report a bug...

My configuration no longer works with the line: report.next.filter=+READY or (+PENDING and scheduled.before:eod and not +BLOCKED)

I believe this is synonymous with: report.next.filter=+PENDING and (-BLOCKED or scheduled.before:eod)

Running task "+PENDING and (-BLOCKED or scheduled.before:eod) returns same message.

• I expected the filter to function.

• Observed behaviour was an error message: task: /usr/src/debug/task/task/src/Task.cpp:2322: float Task::urgency_age() const: Assertionhas ("entry")' failed. zsh: IOT instruction (core dumped) task`

• Running task <filter> with and carried no error. This bug is only with the or keyword.

• Output of task diag:

  
  task 3.0.2
  Platform: Linux

Compiler Version: 13.2.1 20230801 Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64 Compliance: C++17

Build Features Commit: bc86a1e53 CMake: 3.29.2 libuuid: libuuid + uuid_unparse_lower Build type:

Configuration File: /home/username/.config/task/taskrc (found), 5928 bytes, mode 100644 Data: /home/username/.local/share/task (found), dir, mode 40755 TASKRC: /home/username/.config/task/taskrc TASKDATA: /home/username/.local/share/task Locking: Enabled GC: Enabled $EDITOR: nvim Hooks System: Enabled Location: /home/username/.local/share/task/hooks Active: on-add.taskwarrior-autotagger.py (executable) (symlink) on-modify.taskwarrior-autotagger.py (executable) (symlink) on-modify.timewarrior (executable) Inactive: on-add.trackwarrior (not executable) (symlink) on-modify.timetracking (not executable) on-modify.trackwarrior (not executable) (symlink)

Tests Terminal: 264x73 Dups: Scanned 1455 tasks for duplicate UUIDs: No duplicates found Broken ref: Scanned 1455 tasks for broken references: No broken references found

[djmitche]

I don't think this has to do with the filter. Rather, there's some task that for some reason doesn't have an entry property, and Taskwarrior is crashing as a result. I suspect a simple task all would generate the same result.

I don't know how a task would have gotten into this state - the entry property should be added when the task is created (see https://gothenburgbitfactory.org/taskchampion/tasks.html). Finding and removing that task should fix the issue.

We should also update the urgency calculation to be resilient to this circumstance - in fact, any combination of properties must be considered a valid task, as described in https://gothenburgbitfactory.org/taskchampion/tasks.html.

[vanya-robertson]

task all does not throw this error

[djmitche]

Huh, does your task all show urgencies? Does it display all 1455 tasks?

Alternately, does the output of task export show any tasks with no entry property? I suspect grep -v would be sufficient to detect this.

[vanya-robertson]

task all does not show urgencies. task export shows the same error message as above. I now have 1464 tasks, and task all prints all 1464 of them.

[djmitche]

Hm, it seems like you'll need to go task-by-task to figure out which one is missing the entry property, and delete or update that task.

Do you have any idea how the task got in that state?

[vanya-robertson]

Taskwarrior 3.0 is noticeably slower on my device than 2.0 was. I may have closed the terminal before an operation finished.

[djmitche]

(keeping open until you can get your taskdb fixed)

[vanya-robertson]

Resolved. There was a pending task with no create time. I believe this occurred due to me closing the terminal before it had finished generating my recurring tasks, when I had just started up tasksh.