Compatibility with git-as-a-backend hooks

[fullstopslash]

Description

So firstly, as far as I can tell this isn't an issue with taskwarrior-tui directly, more a possible issue with how hooks are run as a result of it. I've been trying to set up some hooks that allow one to use git as a backend for one's task data storage. There are plenty of reason's I don't want to use the taskwarrior sync feature. The biggest being it doesn't really allow for any meaningful encryption of data at rest. With git and git-crypt I can manage that myself. So that being the case, there are a few sets of hooks to help this along. taskwarrior-hooks and taskwarrior-data, the second one being the more real elegant of the two, as it also accomplishes sync in the background. Anyhow, with all that as context, whenever I have either set of these hooks enabled while I'm running taskwarrior-tui my cpu usage skyrockets. I assume it's because task is running it's on-launch script over and over, simply pummeling the cpu in the process. Actually I can confirm this is the case because the tasks that the hook launches keep showing up in htop while tw-tui is active.

Solution Change the way taskwarrior-tui interacts with hooks? This is a huge ask I assume, because taskwarrior-tui seems to be keeping the data displayed fresh with what's in the task database, which is the right thing to do in my opinion.

Additional context Perhaps there could be a setting for taskwarrior-tui to manage how often it asks task for fresh data?

[kdheepak]

You can change the refresh time from 250ms to 0, and then it’ll only refresh when you hit the r button. Would that solve you problem? I’m on my mobile at the moment and I can paste the exact code to add to your .taskrc when I’m back at a computer.

[fullstopslash]

I added uda.taskwarrior-tui.tick-rate=4000 as a setting in my .taskrc and it definitely helps the situation. Strangely enough uda.taskwarrior-tui.tick-rate=0 doesn't actually seem to shut it off for me, as it keeps refreshing at the original rate.

[kdheepak]

Hmm. Maybe I’m misremembering? Or there’s a bug. I’ll look into it this week.

[kdheepak]

I think that's how it worked in an older version. I have a PR that converts 0 to u64::MAX, and that should resolve that issue.

Does using this tick-rate resolve your original issue?

[fullstopslash]

Now if tick-rate is set to 0 the mac build gives this error:

Backtrace omitted. Run with RUST_BACKTRACE=1 to display it.
Run with RUST_BACKTRACE=full to include source snippets.

The application panicked (crashed).
  overflow when adding duration to instant
in library/std/src/time.rs, line 403
thread: main

Unrelated to all of this whenever I hit r to refresh it freezes the interface for a number of seconds. I just noticed that a low tick-rate makes loading task details as slow as the tick-rate, but at least it makes the hook problem less of an issue! Thanks again for this amazing tool!

[kdheepak]

I think it freezes because task export (Can you run that in your shell to verify?) takes a long time to complete for you, because you have a lot of tasks.

Thanks for reporting the crash. I’ll look into this.

[kdheepak]

Thanks for reporting the crash.

I updated the PR to support 0 meaning a refresh rate for about a year. I think once I get to refactoring the codebase (#349) I'll be able to make this more clean and have it only manually refresh. For now, this is the best compromise I could think of.

[fullstopslash]

running time task export results in user=0.06s system=0.05s cpu=38% total=0.260 That doesn't seem too slow to me.

[kdheepak]

That is quite strange.

Hitting r calls update(true):

https://github.com/kdheepak/taskwarrior-tui/blob/dfa4361379de6a16cd0b0ee3565c74025ac56946/src/app.rs#L2480-L2481

I'm not sure if you want to help debug this, I would super appreciate it. Here's the update function:

https://github.com/kdheepak/taskwarrior-tui/blob/dfa4361379de6a16cd0b0ee3565c74025ac56946/src/app.rs#L1241-L1273

If you add debug!("before ...") before various lines in this function, you'll be able to get the log file and timing information from the log file to see what is going on. You'll need the following environment variables:

export TASKWARRIOR_TUI_DATA=`pwd`/path/to/any/data/folder
export TASKWARRIOR_TUI_LOG_LEVEL=debug

I have this environment variable: export TASKWARRIOR_TUI_DATA=`pwd`/tests/data/.data and this is the log file:

This can help us find which functionality is causing the freeze.

[fullstopslash]

I'd certainly be more than willing to take a look at it sometime this week!