Bug #315

Unexpected behaviour - marking task as done releases task ID

Added by Cory Donnelly 253 days ago. Updated 185 days ago.

Status:Assigned Start:11/17/2009
Priority:Normal Due date:
To:Paul Beckingham % Done:

20%
Category:core Spent time: 2.00 hours
Target version:2.0.x - Katana Estimated time:10.00 hours

Description

Consider:

$ task add foo
Created task 88
$ task add bar
Created task 89
$ task do 88
Completed 88 'foo'
Marked 1 task as done
$ task do 89
Task 89 not found

This doesn't seem consistent with other areas of task -- I thought that tasks shouldn't be renumbered until a list command is completed.

Related issues

related to Feature #42 Purge command to remove deleted tasks New 05/25/2009
related to Feature #55 Permanent ID numbers New 05/25/2009
related to Feature #152 add "purge" command Rejected 06/22/2009

History

Updated by Paul Beckingham 253 days ago

  • Status changed from New to Assigned
  • Target version set to 1.8.5 - PAUL

You're right, this is not consistent with intended behavior. It is also inconsistent with this simple test:

$ cat > x
data.location=.
^D

$ t rc:x add foo
Created task 1

$ t rc:x add bar
Created task 2

$ t rc:x do 1
Completed 1 'foo'
Marked 1 task as done

$ t rc:x do 2
Completed 2 'bar'
Marked 1 task as done

$ t rc:x li
No matches.

$ t rc:x completed

Complete   Project Pri Age     Description
11/17/2009             27 secs foo
11/17/2009             24 secs bar

2 tasks

Updated by Paul Beckingham 239 days ago

Cannot replicate. Can anyone else?

Updated by Cory Donnelly 239 days ago

I've uncovered the root cause of this issue -- enabling the shadow feature via .taskrc effectively runs the ls/list (depending on configuration) on the users' behalf immediately after a `task done` is executed. This updates the IDs of the affected tasks unexpectedly:

With shadow.notify=on:

$ task do 2
Completed 2 'foo2'
Marked 1 task as done
[Shadow file 'shadow.txt' updated]
$

Consider this unexpected expected behaviour. :)

Updated by John Florian 237 days ago

I swear I've seen this and I don't use the shadow feature at all. IIRC, the usage pattern may have been something like add several new tasks then mark one or more of those done all w/o any reports in between. I would have reported it at the time, but was already near a stack overflow in the ol' brain.

Updated by Paul Beckingham 236 days ago

  • Target version changed from 1.8.5 - PAUL to 1.9.0 - Kuwagata
  • % Done changed from 0 to 20
  • Estimated time set to 10.00

This is a tricky one to fix. I'm pushing it back to the 1.9.0 release to allow time for some rethinking of the shadow file call sequence.

Updated by Paul Beckingham 185 days ago

  • Target version changed from 1.9.0 - Kuwagata to 2.0.x - Katana

Pushing this even further back to 2.0.0. This is a symptom of interference between shadow files and TDB::gc calls. With shadow files being reimplemented (using hooks) in 2.0.0 (hopefully) this may just go away by itself. To fix it now would require more substantial work on the TDB object than I'd like to undergo.

Also available in: Atom PDF