[TW-1702] On-modify hook script only partially modifies other task

[taskwarrior]

Robin Green on 2015-09-19T18:43:02Z says:

I have written an on-modify hook which ask the user what to do if due dates are inconsistent with due dates of dependencies, and if the user so requests, either tries to modify the due dates of the current task, or of the dependencies.

This hook seems to work when the user opts to modify the current task, but after I launch task modify from the hook to modify a dependency, the change history in task info shows the due date as having been changed, but the due date shown in the output of the very same task info command shows that the due date has not in fact been changed, contrary to the change history.

[taskwarrior]

Migrated metadata:

Created: 2015-09-19T18:43:02Z
Modified: 2015-09-20T19:48:17Z

[taskwarrior]

Paul Beckingham on 2015-09-19T19:20:16Z says:

I have asked subject matter experts to jump in.

[taskwarrior]

Wim Schuermann on 2015-09-20T17:30:51Z says:

This is a known problem with the current approach. In a nutshell, here's what happens: The Taskwarrior instance you call (T1) calls the on-modify hook (H1), which in turn calls a second Taskwarrior instance (T2) which modifies other tasks.

1. T1 reads the data files, calls H1, which calls T2
2. T2 reads the data files, modifies data, writes the data files, exits
3. T1 modifies data, writes the data files, exits

You can probably spot the problem - T1 and T2 read the same data, but write different data. T2's changes get overwritten by T1's changes. What you call a hook script "partially modifying" tasks stems from the fact that undo.data is appended to during changes, meaning that T2's modifications are logged in undo.data despite the actual changes to pending.data being overwritten by T1 later on.

In order to prevent this, Taskwarrior would have to lock the data files before calling on-modify (and possibly on-add) hooks. In the meantime, there probably needs to be a bigger "DO NOT TRY TO CALL TASKWARRIOR FROM HOOK SCRIPTS IF YOU DON'T KNOW WHAT YOU'RE DOING" warning. Still, it's not an ideal situation.

If you want to work around this, take a look at the "blocks attribute" hook on [http://taskwarrior.org/tools/#hooks] to see one way of dealing with this. It writes changes to other tasks to a file that is read by an on-launch hook the next time Taskwarrior is run.

[taskwarrior]

Paul Beckingham on 2015-09-20T19:28:43Z says:

How about T1 runs the on-modify hook and writes commands (task <uuid> modify ...) to a file, then an on-exit hook runs, and processes those commands, then removes the file. This would be more synchronous than waiting for the next on-launch, and by the time on-exit runs, the files are unlocked.

[taskwarrior]

Wim Schuermann on 2015-09-20T19:48:17Z says:

I explained this in #taskwarrior after you asked, but didn't preface it with your name. I'll copy&paste here because it's probably worth mentioning it:

15:20:02 < tbabej> Well, one possible workaround would be to use 'at' to schedule the 
                   modification at some later point, i.e. 2 seconds later.
15:20:45 < pbeckingham> Why on-launch, and not on-exit?
15:24:37 < tbabej> pbeckingham: A good question.
15:25:18 < tbabej> bqf: Satisfy our curiosity.
15:30:08 < bqf> tbabej: with "at" you get race conditions again. so no, not an 
                option. on-launch because that way potential errors in the delayed 
                modifications block the next command from running. on-exit would fail 
                in the on-exit hook, but still allow more modifications with other 
                commands. on-exit is usually best used for "observation" type hooks.

If you don't care about error handling and are willing to drop modifications that lead to problems, then an on-exit hook is fine of course.