taskwarrior

taskwarrior copied to clipboard

The use of wait:later or wait:someday break synchronisation with taskd servers.

• What command(s) did you run? I have 2 devices, a computer running Arch Linux and a phone running Android 10. In the ArchLinux computer I ran task add some task wait:later task sync Then, in my Android phone I ran task sync (these were run in both Taswarrior for Android as well as Foreground)

• What did you expect to happen? I expected synchronisation to be successful.

• What actually happened? I got the error '253402128000' is not a valid date in the 'm/d/Y' format..

• Paste the output of the task diag command.

task 2.6.1 Platform: Linux

Compiler Version: 11.1.0 Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64 Compliance: C++17

Build Features CMake: 3.21.3 libuuid: libuuid + uuid_unparse_lower libgnutls: 3.7.2 Build type:

Configuration File: /home/pablo/.taskrc (found), 1985 bytes, mode 100644 Data: /home/pablo/.task (found), dir, mode 40755 Locking: Enabled GC: Enabled $EDITOR: nvim Server: tansanchez.net:53589 CA: /home/pablo/.task/ca.cert.pem, readable, 4001 bytes Certificate: /home/pablo/.task/pablo.cert.pem, readable, 3765 bytes Key: /home/pablo/.task/pablo.key.pem, readable, 24745 bytes Trust: strict Ciphers: NORMAL Creds: tansanchez/pablo/************************************

Hooks System: Enabled Location: /home/pablo/.task/hooks Active: on-modify.timewarrior (executable) Inactive:

Tests Terminal: 120x30 Dups: Scanned 173 tasks for duplicate UUIDs: No duplicates found Broken ref: Scanned 173 tasks for broken references: No broken references found

I though this error might have to do with the recent changes made to Taskwarrior in order to support 64 bit timestamps so I thought it might be the clients not handling that properly so, since Taskwarrior for Android is no longer in development, I decided to create an issue in the Foreground project. I got a suggestion there so I tried to remove the .data files and resync (prior copying the old ones) and I got the exact same error.

I agree with the response I got. It seems taskd accepts anything as a date but when it is delivered to the clients, it checks the timestamp and fails.

For the time being I have set the tasks that are causing the problem as wait:tomorrow but even after making that change, the synchronisation won't happen. When I look at the data, the only place where I can find the problematic timestamp is in the undo.data. Is it possible to purge the undo.data just for the sake of getting the server to sync properly while this bug is being fixed.

Thaks in advance for your help.

@psa-anddev Thanks for the clear bug report! One more important piece of information would be needed for us to dig down deeper - what is the version of taskd running at tansanchez.net:53589? :slightly_smiling_face:

@tbabej my reproduce is briefly described at https://github.com/bgregos/foreground/issues/135#issuecomment-991978434. I was using taskd 1.1.0.

@psa-anddev, are you saying you only have something like 99991231T000000Z in ~/.task/undo.data, and nowhere in any of ~/.task/{backlog/completed/pending}.data? I'd guess you still have some timestamps like that in $TASKDDATA/orgs/$org/users/$userKey/tx.data.

@tbabej You are correct. I should have pointed that out. My taskd version is also 1.1.0. I can confirm that locally, I only have the offending timestamp in the undo.data. This is after me changing the waiting to a vaild date. wait:tomorrow rather than wait:later or wait:someday. I pointed that out in case the undo data is also sync.

I can also confirm that the tx.data for the user in the server does have the offending date but in that file it is not stored as a timestamp but as a date. So, I can see records of waiting with the value: 99991230T000000Z in the tx.data file.

So, here is my hypothesis. The server is storing dates formatted like this yyyyMMddHHMMssZ but the client is storing 32 bit timestamps. So, the server somehow converts the date to a timestamp and then checks the timestamp to make sure the date is in the future or something like that but because of the 2038 bug, it thinks the date is in the past. If you use any existing epoch converter and pass 253402128000 it will give you the 11th January 1978.

If I am correct, there are two possible ways to tackle this. One would be to get rid of timestamps in the client and just use formatted dates which would eliminate the issue for good (or at least until we reach the year 10.000) or make both task and taskd to communicate with one another using 64 bit timestamps which I don't know how far they go.

EDIT: As I was writing this comment, I also thought about a potential quick fix to do which is to change the behaviour of wait:later and wait:someday. Instead of waiting for 99991230T000000Z it could just calculate a date in the future. I think this could also be an improvement. Let's say that wait:someday calculated a 2 year date from now and wait:later calculated let's say a 2 months date. That would temporally fix the issue (until 2038) and it would provide almost automatically reminders for users upon reviewing their tasks. Perhaps, that is something to consider for the next release of Taskwarrior.

Oh shoot, above I think I suggested to look for 9999 in pending.data and completed.data. I forgot those files probably don't use the YYYYMMDDTHHMMSSZ format. I say probably because that file format changes between task versions, and I don't keep up on it. You could either check those two files for a number close to 53402128000, or I guess check task export for a string like 9999.

Regarding your hypothesis, I think that Taskserver gets requests, stores state in tx.data, and sends responses, all with the YYYYMMDDTHHMMSSZ format. I think you saw the format evident in tx.data. That requests and responses also use this format, I think is supported by browsing at https://taskwarrior.org/docs/design/index.html. Also I've written one of these mobile taskd clients, so I've come to get somewhat familiar with the format of Taskserver requests and responses.

My impression is, as Taskserver begins generating the response to the client, if the response is to include such dates, Taskserver spontaneously errors on the date, I guess because of some implementation detail, and sends the code: 500 error to the client.

Regarding solutions like wait:tomorrow, you might consider task calc soy+10y, which outputs 2030-12-30T00:00:00, or add +2d to account for the leap years apparently. Or task calc tod+2y, etc, whatever you think is a good value for someday.

@bradyt, you are absolutely correct. As a test, I decided to change the tx.data file so that every date that started with 999 would start with 2030. Once that change is done, I can synchronise both in my Arch system deleting the data files as well as with both Foreground and Taskwarrior for Android. However, this is just a workaround. I'd love to be able to use wait:later and wait:someday but for the time being, I'm going to set those to be a date in the year 2030 for now.

I'll keep in track with this issue since I'd like to stop having to set an actual date for something I just want to do later.

Can confirm seeing this issue at app.wingtask.com:53589.

Taskd version: 1.2.0
Taskwarrior client: 2.6.1

I have a parser I wrote in the UI of WingTask, that converts "someday" to 2038-01-18 based on what I saw in the docs, and that syncs fine, but if I use taskwarrior CLI where "someday" becomes 99991231T000000Z then sync throws 500.

I'm also experiencing this error with both freecinc and inthe.am.

I am also experiencing the same issue, adding wait:someday to any of the tasks makes me unable to sync. I get a different message though:

Syncing with taskd.eug-vs.xyz:53589

Sync failed.  The Taskserver returned error: 500 Unrecognized Taskwarrior file format or blank line in data.

My client is 2.6.2 and the server is latest dev branch 1.2.0 (commit 9794cff). Initially I thought it has something to do with the fact that my server and client are in the different timezones, but that's not the case. Anyway in my timezone the wait value is 99991229T210000Z in backlog.data and 253402117200 in {pending,undo}.data.

Yes, this stops syncing to inthe.im

Yup, can confirm, this is messing with freecinc as well.

Is there any plan to fix this?

The taskchampion sync model will not have this problem. At this point, that's the most likely path to resolution for this issue.

Very disappointing. This bit me. :(

Sorry for the necro but should consider removing someday as a valid option if it bricks syncing.

For anyone coming after me, here is a quick solution:

If you have one computer that has all the tasks and you are running your own sync server: move tx.data out of the folder (it will be your user folder inside of the org folder) / rename to something besides tx.data then run task sync init to entirely start over after you have modified the task that has the due date of someday.

Closed because taskserver/taskd is no longer supported. The new sync system sees only encrypted task data, so the particulars of wait times do not affect it.

@djmitche is taskd really no longer supported by taskwarrior? Has there been a deprecation notice? The only other alternative appears to be a reference implementation.

Yes, 3.0 has an entirely new sync system. There's an open issue to mark it as deprecated - #3293.

The alternatives are outlined in the task-sync(5) manpage -- cloud sync and taskchampion-sync-server. We just broke the latter into its own repo and I'm confident that it will see some active work to make it more production ready.