Inconsistent tasks for list and delete actions when using filters

[00willo]

To report a bug...

• What command(s) did you run?

  task +SCHEDULED /Mow/ list
  task +SCHEDULED /Mow/ delete
  

• What did you expect to happen? The same set of tasks to be deleted as were listed.

• What actually happened? Based on the count and looking at the resulting task IDs. It has 65 tasks in the first list and then attempts to delete 82 tasks, of which includes the recurring task template, and already completed tasks.

• Paste the output of the task diag command.

task 2.6.2
   Platform: Darwin

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

Build Features
      CMake: 3.24.1
    libuuid: libuuid + uuid_unparse_lower
  libgnutls: 3.7.7
 Build type: Release

Configuration
       File: /Users/user/.taskrc (found), 4112 bytes, mode 100644
       Data: /Users/user/.task (found), dir, mode 40755
    Locking: Enabled
         GC: Enabled
     Server:
         CA: -
Certificate: -
        Key: -
      Trust: strict
    Ciphers: NORMAL
      Creds:

Hooks
     System: Enabled
   Location: /Users/user/.task/hooks
     Active: on-add.blocks_attr.py    (executable)
             on-launch.blocks_attr.py (executable)
             on-modify.blocks_attr.py (executable)
             on-modify.timewarrior    (executable)
   Inactive:

Tests
   Terminal: 213x63
       Dups: Scanned 951 tasks for duplicate UUIDs:
             No duplicates found
 Broken ref: Scanned 951 tasks for broken references:
             No broken references found

[dathanb]

I don't think this is a bug. Filters are conjunctive, so task filter1 filter2 only matches tasks that match both filter1 and filter2. That's the expected behavior.

list isn't a command, it's a report, and it has its own filter:

$ task show report.list.filter

Config Variable    Value
report.list.filter status:pending -WAITING

So when you task +SCHEDULED /Mow/ list, the effective filter is task +SCHEDULED /Mow/ status:pending -WAITING. Which of course excludes deleted tasks.

delete, on the other hand, IS a command. So it's not applying its own filter, and just uses the +SCHEDULED /Mow/ filter you passed, which does match deleted tasks.

So it's not totally obvious, but both are working as designed, I think.