Recurring tasks do not have an id when created

[mskelton]

trafficstars

When I run task at the beginning of the day, my daily recurring tasks show on the list but have an empty id. The odd thing is this happens on my work computer, but not my personal computer.

The command I use to create the recurring tasks:

task add recur:weekdays due:eod+1day wait:tomorrow Do something

Screenshot

I cut out some of the screenshot to remove private information.

[bradyt]

Can you provide steps for a minimal broken example? Also task version and how you installed?

I tried the steps you provided, illustrated below, and the tasks have ids.

% mkdir /tmp/no_id_test
% cd /tmp/no_id_test
% HOME=$(pwd)
% touch .taskrc
% task add recur:weekdays due:eod+1day wait:tomorrow Do something; task all
Created task 1 (recurrence template).

ID St UUID     Age R Wait Due        Description 
 1 R  f7938506   - R 5h   2022-03-10 Do something
 2 W  9c4073c1   - R 5h   2022-03-10 Do something

2 tasks
Creating recurring task instance 'Do something'

You may want to verify the status on those tasks with missing ids, check their uuid to distinguish between tasks with identical descriptions, and if they don't have an id, verify that they are in ~/.task/pending.data (search by uuid), and if not, figure out why they are in ~/.task/completed.data. If I understand correctly, a task has an id if and only if the task is in ~/.task/pending.data.

[mskelton]

Sorry for the delay, I keep forgetting to run task all in the morning to check the statuses. Here is what I found

[bradyt]

Can you join #taskwarrior channel on Libera.chat, via IRC or Matrix bridge? I'm not sure what questions would be effective in this GitHub medium.

[bradyt]

I can reproduce something like what you see, with the following:

> mkdir /tmp/no_id_test
> cd /tmp/no_id_test
> touch .taskrc
> HOME=$(pwd)
> task add foo; mv .task/pending.data .task/completed.data; task all; task all
Created task 1.

ID St UUID     Age Description
 - P  0c5fb310   - foo

1 task

ID St UUID     Age Description
 1 P  0c5fb310   - foo

1 task

What I've done there, is manually moved the pending task from the pending file to the completed file. As I mentioned above, I believe a task has an id if and only if the task is in the pending file.

Notice that on the second call, the task now has an id, I think Taskwarrior has moved the task from ~/.task/completed.data to ~/.task/pending.data, because the status is pending.

So my impression is, you somehow have tasks with status:"pending" in your .task/completed.data file. Can you research your system to determine what is causing that? Are you using Taskwarrior hooks?

[bradyt]

Here's a cleaner reproduce that doesn't require the manual changes to files:

% task log foo; task +LATEST modify status:pending; task all; task all
Modifying task ae1e34ac 'foo'.
Modified 1 task.

ID St UUID     Age Description
 - P  ae1e34ac   - foo

1 task

ID St UUID     Age Description
 1 P  ae1e34ac   - foo

1 task

This shows that a task can be not pending, and in the completed file, and right after changing status to pending, there is no id, but on next call it has an id, that is it's been moved to the pending file.

[bradyt]

If you're interested, here's a webpage about task ids and "garbage collection": https://taskwarrior.org/docs/ids.html.

[mskelton]

So, I did some more investigation and it looks to be related to hooks. I have only one very simple on add hook to auto link Jira tickets and when I disable that, it starts working just fine.

Here is the hook source.

#!/usr/bin/env python
import sys
import re
import json

added_task = json.loads(sys.stdin.readline())
original = added_task['description']

added_task['description'] = re.sub(
    r'\b((?:FE|BE|SRE)-\d+)\b',
    r'https://site.atlassian.net/browse/\1',
    original,
    flags=re.IGNORECASE
)

print(json.dumps(added_task))

if original != added_task['description']:
    print('Jira link added')

sys.exit(0)

[bradyt]

I tried adding that hook to my system, and I still don't see any pending tasks lacking an id. I think we still don't have a minimal reproducible broken example.

I guess you want to avoid messing up your Jira data. Can you create a Jira testing account, and create some HOME=/tmp/testing directory where you can find the minimum configuration needed to reproduce the issue?

Maybe this requires both the hook, as well as some ~/.taskrc configuration? Does this require installing bugzilla? If so, does the bug require bugzilla, the hook, as well as some extra lines in ~/.taskrc?

[mskelton]

Sorry for the delay again. Here is what I was able to do to reproduce it.

mkdir -p /tmp/testing/.config/task/hooks/

HOME=/tmp/testing

echo "hooks.location=~/.config/task/hooks" > /tmp/testing/.taskrc
hook=$(cat <<EOF
#!/usr/bin/env python
import sys
import re
import json

added_task = json.loads(sys.stdin.readline())
original = added_task['description']

added_task['description'] = re.sub(
    r'\b((?:FE|BE|IT)-\d+)\b',
    r'https://site.atlassian.net/browse/\1',
    original,
    flags=re.IGNORECASE
)

print(json.dumps(added_task))

if original != added_task['description']:
    print('Jira link added')

sys.exit(0)
EOF
)

echo "$hook" > /tmp/testing/.config/task/hooks/on-add-jira.py
chmod +x /tmp/testing/.config/task/hooks/on-add-jira.py

task add recur:weekdays due:eod+1day wait:tomorrow Finish FE-12
task all

Running this in bash produces the following output:

Running the same example without the hook works fine.

mkdir -p /tmp/testing

HOME=/tmp/testing

echo "" > /tmp/testing/.taskrc

task add recur:weekdays due:eod+1day wait:tomorrow Finish FE-12
task all

[bradyt]

Great! I was able to reproduce the issue. I did it in Docker because I myself was having trouble getting it to work on local /tmp/. And since I put it in Docker, I went ahead and used usual ~/, rather than /tmp/. I also added a little bit of debugging. If anyone is considering python2 vs python3, I think the reproduce still works if you install python3, and update the shebang line with #!/usr/bin/env python3.

click me

# script.sh
mkdir -p ~/.config/task/hooks/

echo "gc=off"                              >> ~/.taskrc
echo "debug=1"                             >> ~/.taskrc
echo "debug.hooks=2"                       >> ~/.taskrc
echo "hooks.location=~/.config/task/hooks" >> ~/.taskrc
hook=$(cat <<EOF
#!/usr/bin/env python
import sys
import re
import json

added_task = json.loads(sys.stdin.readline())
original = added_task['description']

added_task['description'] = re.sub(
    r'\b((?:FE|BE|IT)-\d+)\b',
    r'https://site.atlassian.net/browse/\1',
    original,
    flags=re.IGNORECASE
)

print(json.dumps(added_task))

if original != added_task['description']:
    print('Jira link added')

sys.exit(0)
EOF
)

echo "$hook" > ~/.config/task/hooks/on-add-jira.py
chmod +x       ~/.config/task/hooks/on-add-jira.py

task add recur:weekdays due:eod+1day wait:tomorrow Finish FE-12
task all

# Dockerfile
FROM alpine

RUN apk add --no-cache --update task
RUN apk add --no-cache --update python2

RUN touch ~/.taskrc

ADD script.sh ~/script.sh

WORKDIR ~/

# Makefile
run:
	docker build -t this . && docker run -it this

Maybe one clue for those who know how to read these, is the following block in debug:

  pending.data rw O T0002+001~001-000 L0001+000
completed.data rw - T0000+000~000-000 L0000+000
     undo.data rw O T0000+000~000-000 L0007+007
  backlog.data rw O T0000+000~000-000 L0002+002

I'm guessing that Taskwarrior maintains the new recurrence child task as some sort of draft, outside of the ~/.task/pending.data file, when a hook is involved, so we don't get the line number in the call that generates the task.

[mskelton]

@bradyt Thanks for the help! Let me know if you need any other information, but now that it's reproducible, I'm guessing at this point it's just waiting for prioritization.

[jaker-dotcom]

So, I did some more investigation and it looks to be related to hooks. I have only one very simple on add hook to auto link Jira tickets and when I disable that, it starts working just fine.

I only recently noticed that issue too and also within the last month I added my first hook. It is different hook though (task add taskname annotate: annotation).

Just saying because it might coincide.

When I tested now I did not experience the issue with or without the hook so I can't confirm.

I think I experienced it when using ls .task/pending.data | entr -c task rc.gc=0 only.