On connect fail, don't close tasks

[wimvinckier]

I see #866 and #1017 which are related but I currently don't see a solution. If a connection to a service fails, all related tasks are closed. When the connection is restored, the tasks are opened again.

In most cases this works correctly but it's causing issues with the logseq system. When bugwarrior restores the connection, the UUID sometimes changes. This means that it creates a new UUID and does not reopen the previous task but creates a new one.
So if you added tasks or changed the project, that information gets lost.

From my point of view, bugwarrior should leave the tasks as is if it can't connect to the server.

[ryneeverett]

From my point of view, bugwarrior should leave the tasks as is if it can't connect to the server.

That is correct. Can you verify what version of bugwarrior you're using and how you installed?

[ryneeverett]

A copy of the console output, particularly the error messages, would also be very helpful for understanding these kinds of problems.

In most cases this works correctly but it's causing issues with the logseq system. When bugwarrior restores the connection, the UUID sometimes changes. This means that it creates a new UUID and does not reopen the previous task but creates a new one.
So if you added tasks or changed the project, that information gets lost.

I'm thinking this might be the entire issue and the lost connection might be unrelated. (Or only related insofar as it is associated with the UUID changing.) From the service:

    UNIQUE_KEY = (ID, UUID)

Assuming the service succeeds, I'm fairly sure bugwarrior will close any tasks that have the UDA's associated with these variables which are not returned by the service. In other words, if UUID is not a stable value, that will cause the associated tasks to be closed and replaced with new tasks even if the service succeeds.

@scross01 I'm wondering if we could just use ID here? (Assuming ID is a stable value.)

[ryneeverett]

We should probably also add to the UNIQUE_KEY docs that these values need to be immutable.

Edit: I see it does say that in the tutorial which is probably sufficient.

[scross01]

Logseq tasks are uniquely identified by the UUID of the block. The blocks UUID is stable for the lifetime of that block, but there some edge cases that can cause the ids to change (i.e. be treated as a new block/task):

• Performing a Re-index of the Logseq graph will cause all UUIDs to change
• If you cut & paste a task line Logseq treats it as a new block and assigns it a new UUID
• Sync conflict resolution when editing on multiple devices (e.g. though iCloud, Dropbox, etc) cloud also cause a UUID to change if the conflict affects the task block.

[ryneeverett]

@scross01 Ideally UNIQUE_KEY values would be less mutable than that. Is ID better in this regard? And guaranteed unique?

[scross01]

@ryneeverett unfortunately not. The ID seems to be row id key for the block in the Logseq DB, both the ID and UUID appear to change in the scenarios above.

[ryneeverett]

I forgot that this information is already in the logseq docs. Unless we get more info from the OP I'm going to conclude that they were confused by this behavior and incorrectly blamed a faulty network connection (which should have nothing to do with UUID's changing).

I think it's ok if our UNIQUE_KEY isn't technically immutable but only practically immutable. The reindex changing all the UUID's breaks this assumption and strikes me as unreasonable. If we wanted to improve this behavior I think the first thing to do would be to understand why logseq changes the UUID's on reindex and see if we can convince them not to.

[scross01]

Full Re-indexing is a user initiated action to recover from a corrupted DB, it shouldn't generally be needed. The challenge is that Logseq is primarily a journaling app on top of Markdown files in a structured directory, the task within the Markdown files themselves have no intrinsic identity, Logseq builds up its own index of the blocks (Markdown bullets) within each Markdown file.

A new Logseq v2 (aka DB version) has been in development for a while, and that will switch from the text files to a DB centric data store, that may help make block/task IDs more fixed, but I've not tried the development version, so not sure.

[wimvinckier]

Hi, I'm back behind my computer after the holidays so I can finally react.

From my point of view, bugwarrior should leave the tasks as is if it can't connect to the server.

That is correct. Can you verify what version of bugwarrior you're using and how you installed?

bugwarrior, version 2.0.0.post0
I'm using the develop branch of bugwarrior, currently tag 768c90f

@ryneeverett It's hard to provide a log message. There is not really an error message. On the first run bugwarrior fails to connect and on a second run it connects correctly but "some" uid's are changed. I have no view on which are changed and why. I just noticed a gap in the history of the item in taskwarrior. Digging deeper I found closed items in taskwarrior which referred to another uuid.

Logseq tasks are uniquely identified by the UUID of the block. The blocks UUID is stable for the lifetime of that block, but there some edge cases that can cause the ids to change (i.e. be treated as a new block/task):

* Performing a Re-index of the Logseq graph will cause all UUIDs to change
* If you cut & paste a task line Logseq treats it as a new block and assigns it a new UUID
* Sync conflict resolution when editing on multiple devices (e.g. though iCloud, Dropbox, etc) cloud also cause a UUID to change if the conflict affects the task block.

@scross01 unfortunately none of this happened to the items, or at least not that I'm aware of. But I'll keep it in mind and tag conflicting items. That way I can exclude this. I don't use the re-index option and if I want to copy a task, I use the block ref.

It looks like it happens on blocks which changes from TODO to DOING but it needs some extra investigation. My tmux shows the active task and I set the task to DOING when a task is started. From time to time the task gets closed automatically and recently I discovered that the UUID was changed. That's why I opened this ticket.

I think the previous paragraph is incorrect. I think I noticed the issue because old items had a much higher number in taskwarrior than expected. I'll keep a closer look on it.

[wimvinckier]

My removed paragraph seems to be correct but not related to this issue. I'll create a new issue for this.