-
I just investigated some Foreground behavior, and found it fairly surprising, and would like to understand a little more.
I was expecting "bar" to not make it to the server. So I am impressed that it made it there. You seem to have avoided a common issue users experience with taskd clients. I watched the requests and response in the server. Magically, Foreground sends the "bar" update, but not the client sync key. I thought that maybe toggling Foreground's "Enable Sync" off and on again perhaps always removed the client sync key. But watching the request/response on Taskserver, I see that is not the case. I tried searching the repo for "Client sync key not found", imagining that you have a special case to remove the sync key from the request when toggling "Enable Sync", in that case, but a cursory search did not suggest this. What magic do you have here, and assuming it was authored by yourself (not some magic in the older Java project), how did you decide on this solution? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
I speculate there's a potential surprise here. User reported issue at another mobile taskd client, apparently created by accidentally deleting tx.data on server. In the following comment, I try to illustrate how Foreground's behavior could lead to surprise:
I understand this is an edge case, and probably not a priority, but thought you might want to be aware of the illustration. FYI, I've tried to illustrate some related examples and request "official" advice with Taskwarrior team, but I don't think it's a priority for them. For example contributors may prefer to work on a new server, |
Beta Was this translation helpful? Give feedback.
-
To answer your initial question: While I don't have a taskserver set up right now to test with, here's what's happening on Foreground's side:
Hopefully that helps! |
Beta Was this translation helpful? Give feedback.
-
What I think might be happening in the scenario in your second post is that foreground is only sending the changed tasks in its initial sync process. Here's a breakdown of the process in a faux table:
* The client never receives "2" because Foreground sent "2" to the server and "2" exits Foreground's modified task list. It is then not sent on re-init because Foreground currently only sends modified tasks on sync init (hence why "3" appears but not "2") @bradyt Do you think Foreground should be sending its entire task list on first sync? In the happy path case where the user creates a bunch of tasks and then inits sync for the first time, Foreground's behavior of sending only modified tasks is fine since all tasks are modified. I can see why it causes an issue when trying to recover from a failed server. |
Beta Was this translation helpful? Give feedback.
To answer your initial question:
While I don't have a taskserver set up right now to test with, here's what's happening on Foreground's side: