task delete should also purge

[ksandvik]

To request a feature...

• Clearly describe the feature.
  task delete should have an option or a flag to purge at the same time

• Clearly state the use case. We are only interested in use cases, do not waste time with implementation details or suggested syntax.

In 99 of 100 cases I want to purge a task at the same time as I delete it. Just now I don't actually have a single work flow where I need to keep a task around after it has been deleted. There's no need to also make this verbal with yes/no responses.

• Please see our notes on How to request a feature

[djmitche]

Huh, I didn't realize task purge wouldn't purge a non-deleted task. Maybe we could add an option to it somehow? I'd suggest -f but none of the other Taskwarrior commands take - style flags. Or, maybe that could be a config option?

There is an option to automatically purge deleted tasks after a period of time -- is that sufficient for you? Why do they need to be purged?

[ksandvik]

As mentioned, I have yet to find a case in my taskwarrior workflow where I don't both delete and purge an unnecessary task, doing this all the time. Now I could do do task delete; task purge but then I'm getting all the prompts for asking if I really want to do it (which I want).

I agree that task should never have option flags, rather key words, maybe
task delete permanently or task delete now or task delete purge or something similar.

[djmitche]

Why do you need to purge and not just delete tasks?

[smemsh]

I almost always purge after deleting also, but there are some use cases where I wouldn't, such as when doing infrequent "maintenance" or trimming of my task database, I probably wouldn't purge until the end of making such a pass, once I was satisfied I hadn't deleted anything by mistake.

Purge is useful is so they are removed from the database entirely, and don't show up at all anymore, for example for test/junk tasks that should end up like they never existed. There are some reasons enumerated in #3399 and I was very happy that purge was restored in 3.x, as this was a barrier to upgrade for me.

However I would not want purge to happen automatically, just like I don't want gc to happen automatically; it is better off explicit, so I hope we can have this only be an option (if implemented) and not change it for everyone. The idea of making purge automatically force a deletion first might make sense though...

(Also, not sure if still the case with the TaskChampion backend, but note that 2b88260 seems to imply that gc is done automatically upon purge, and that's another reason not to want to auto-purge when deleting, because it would forcibly change the ID numbers.)

[djmitche]

Deleting test tasks makes sense. But in general I'd recommend setting up your filters, etc. so that deleted tasks don't show up. Then if one is deleted by accident, it's easy to recover it.

Note that weird things will happen if a task is purged and modified on another replica. Imagine task 1444db41 "take out the trash":

• Laptop: task 1444db41 delete; task 1444db41 purge
• Desktop: task 1444db41 done
• Laptop: task sync
• Desktop: task sync
• Laptop: task sync

At the end of this sequence, both replicas will agree that there is a completed task with no description or any other identifying information.

This isn't an issue if there's no sync going on, and shouldn't be a problem for test tasks that aren't modified on multiple replicas. And even if it does happen, it's not going to cause any great harm -- it's just a weird situation [1]. But, this is why I make the recommendation above.

Anyway, optionally allowing task purge to delete tasks before purging them sounds like a reasonable change to me.

[1] Actually, this might cause errors in Taskwarrior right now, but that's a bug -- I'll work on fixing those up.

[smemsh]

Deleting test tasks makes sense. But in general I'd recommend setting up your filters, etc. so that deleted tasks don't show up. Then if one is deleted by accident, it's easy to recover it.

There are two different states here: deleted, and non-existent. People have different workflows. I've read posts from people that use "deleted" to mark tasks as "not now" or "NAKed" and then undelete them later if they get time/permission to work on them (I don't do this, but I've seen it). This is different from not existing...

To extrapolate from your premise, there's no need to even have a "purge" function at all, but I find it useful to have the two different states. I probably would never want to expire deleted tasks, I would rather purge them explicitly if I wanted them gone. It appears that this is the whole reason purge was added: Paul wanted to get rid of ancient tasks from being visible at all on any report or filter (see #1808). I have also seen a couple other use cases when searching issues: removing all traces of automatically-added recurring tasks, and removing all traces of some aborted project. YMMV...

• Laptop: task 1444db41 delete; task 1444db41 purge
• Desktop: task 1444db41 done

I don't know the new sync model; could some kind of conflict-resolution algorithm be used, ie halting sync and forcing manual selection of which truth, or designating a primary replicant that's always right, or earliest/latest update wins? Your scenario would probably only come up with teams working on the same database, or by accident, though, I think?

Actually, your scenario has two different ending states for the task: one where it doesn't exist at all, and one where it exists but is marked completed. (I assume completed tasks are never expired?) That does seem like a fundamental disagreement. Probably if the task exists vs not exists, the existing version should be copied to all the replicants, to be safe?

optionally allowing task purge to delete tasks before purging them sounds like a reasonable change to me.

It probably doesn't need to be optional, since currently it just isn't allowed and a purge would bomb if not yet deleted. I can't see anyone using this guard as a "feature" but rather something they forgot to do (delete it first). And if they deleted without purging, they still want it to be there.

[djmitche]

I don't know the new sync model; could some kind of conflict-resolution algorithm be used, ie halting sync and forcing manual selection of which truth, or designating a primary replicant that's always right, or earliest/latest update wins? Your scenario would probably only come up with teams working on the same database, or by accident, though, I think?

This is a consequence of the conflict-resolution algorithm. Broadly, deleting things is hard in distributed systems, and typically the solution is what is referred to as "tombstones", which means you just mark an object as deleted and then don't show it. And that is exactly of what the "Deleted' status is!

The scenario would come up with a person syncing the same database between multiple systems. I don't really know how teams would use TaskWarrior -- it's not a common use-case, anyway.

Actually, your scenario has two different ending states for the task: one where it doesn't exist at all, and one where it exists but is marked completed. (I assume completed tasks are never expired?) That does seem like a fundamental disagreement. Probably if the task exists vs not exists, the existing version should be copied to all the replicants, to be safe?

Now that I look at that example again, I think the task will always end up deleted on both replicas. I'd need to think for a bit longer to be sure. The sync does guarantee that all replicas end up in the same state -- it's just a question of what state.

Anyway, I bring up the example just to say that there are downsides to purging tasks. If the convenience of not having deleted tasks in task all output is worth those downsides (or if sync is not in use), then the trade-off makes sense.