Closed sdondley closed 2 years ago
I copied over the data again from X to Y and it now works. So that rules out any weird difference between intel and non-intel machine.
But I still can't do a sync init
command. I'd prefer not to have to copy over data to other machines to get it set up each time.
Once the server account is non-empty, I don't think task sync init
is supported. I suspect this is the reason for Could not find common ancestor for
. I believe there are a number of issues on this and related projects, that unfortunately suggest task sync init
in similar scenarios, but in particular, consider my minimal example that may illustrate, at https://github.com/GothenburgBitFactory/taskwarrior/discussions/2739.
I'm not aware that there is currently any official advice for syncing a second client that already has data. Compare discussion at https://github.com/GothenburgBitFactory/taskwarrior/discussions/2740.
Per partial discussion at https://github.com/GothenburgBitFactory/taskwarrior/issues/2751, I'm still wondering if you have reliable data on server. Can you try task sync
from a new client, with no ~/.task/*.data
files, to make sure that Taskserver can send all the data it has successfully? There are scenarios where Taskserver will receive and store data that it can't actually send, and not all clients will reveal the issue. I am not sure yet, but it might be the reason for Unrecognized taskwarrior file format
. If that is the case, you may want to investigate tx.data
to determine what line is causing Taskserver to error, potentially backing it up, and cutting it in half until you find what line in tx.data
is breaking task sync
.
Yeah so I get Unrecognized Taskwarrior file format or blank line in data.
with task sync
after removing all local *.data files. I'll pry open tx.data and see what I might figure out.
OK, having even just one old task in there throws the error. Here is the task:'
{"description":"launch twu local 100 wp site","entry":"20210603T160348Z","modified":"20210901T025630Z","project":"Client.TWU100","status":"pending","uuid":"a856b5df-c81d-480a-a443-d697783bc48e","tags":["sn","st"],"depends":["[\"303e3e10-c257-4d7f-a4b2-1465925c6e50\"","\"7c34a1fc-61f8-49bf-a7c5-390fcf001b89\"","\"a1fe56c3-2214-483b-97b9-da60e8924382\"","\"f5374528-eb1a-4224-991c-04afd7c2de08\"]"]}
See anything wrong with that?
So, i suspect the problem is with how the tasks with a a depends
key works. I did a sync with tasks that did not have this key and there was no problem. Then I added this task:
{"...depends":["[\"303e3e10-c257-4d7f-a4b2-1465925c6e50\"","\"7c34a1fc-61f8-49bf-a7c5-390fcf001b89\"","\"a1fe56c3-2214-483b-97b9-da60e8924382\"","\"f5374528-eb1a-4224-991c-04afd7c2de08\"]"]}
It depends on other tasks. Maybe it's the escaping of quotes? Dunno. I'll set up a clean task with dependencies and see if it looks the same.
ok, so did a quick test, the new tasks have no escaping of double quotes:
bdb-4ff8-9ceb-4e8659e55fff\"","\"7578f6f1-b2bd-48e2-ae16-9147500de802\"]"]}
{"description":"one","entry":"20220318T232625Z","modified":"20220318T232625Z","status":"pending","uuid":"fc2521a2-4a13-431f-a25f-1bb3d798e837"}
{"description":"two","entry":"20220318T232632Z","modified":"20220318T232632Z","status":"pending","uuid":"141b821c-3d7b-48ca-bbc1-d3fe6067af39"}
{"description":"one","entry":"20220318T232625Z","modified":"20220318T232642Z","status":"pending","uuid":"fc2521a2-4a13-431f-a25f-1bb3d798e837","depends":["141b821c-3d7b-48ca-bbc1-d3fe6067af39"]}
6f8ecf86-a437-453b-9025-73186f2c0b99
So I'm going to try a search and replace of the old tx.data file and clean up those escapes.
Recently released task 2.6.2 should accept those stringified depends arrays in a Taskserver response. But I guess taskd 1.2.0 will avoid creating them in storage. Hopefully your experiment will work.
I upgraded to 2.6.2 today with the hopes of fixing it but it did not. Also upgraded to 1.2 yesterday.
OK, so the good news is do a simple :%s/\\"//g
in vim on the tx.data file fixed the problem.
I did get this warning, though: Warning: You have specified that the 'entry' date is after the 'end' date.
Not sure if I should worry about fixing it or not.
Did you iterate on task sync
after rm -r .task/*.data
, to make sure new taskd can send all the storage, and clients can receive all the tasks? (Don't lose your real data with rm
.)
The end/entry might be from recurrence? Not sure.
yeah, adding, then syncing, then deleting, then syncing work fine.
I did have a recurring task at one point. What's the best way to remove that? I think there is a way to remove tasks completely now but I forget how.
OK, awesome. Just deleted all those recurring tasks and that warning is gone now. Thanks for the tip! Now I got a nice clean and happy taskwarrior setup. I feel like a new man!
Machine X is running TW 2.6.1 on intel mac. Machine Y is running TW 2.61. on m1 mac. Server is running taskserver 1.2
X is syncing just fine with server.
Y is having troubles. With task sync init, I get "Unrecognized taskwarrior file format".
I copied over data files from X to Y. I can create a task. But when trying to save task:
Sync failed. The Taskserver returned error: 500 ERROR: Could not find common ancestor for 74125520-b663-46ca-ad57-db3953b0ec8c. Did you skip the 'task sync init' requirement?
JSON export for this task:
[ {"id":2,"description":"Move content from steve.dondley.com to climate change chat site","due":"20230302T030000Z","entry":"20210601T141238Z","modified":"20220313T042533Z","project":"Toolchain","status":"pending","uuid":"74125520-b663-46ca-ad57-db3953b0ec8c","tags":["st"],"urgency":5.78904} ]