Delay in revision update for sub-objects of to-dos

[tobiasviehweger]

Hi,

This is something which is hampering our development for quite some time now, so I wanted to raise an issue for this again. We are syncing tasks using the API, and we stumbled upon the following.

When creating a sub-object of a to-do (like a subtask), the revision of the to-do is updated in a non-synchronous manner. Our sync logic syncs changes to Wunderlist, and afterwards retrieves the to-do once again, to have the correct newest revision (we don't want to / can't calculate the increase locally, since this might change). In our JS code this looks something like this:

function testConcurrency() {
    //Get current version of to-do 1312766152
    wunderlistGetData(wunderlist.baseUrl + '/tasks/1312766152')
    .then(function (todo) {
        console.log('Original Revision:' + todo.revision);
        //Add a new subtask
        return wunderlistAjaxData(wunderlist.baseUrl + '/subtasks', yasoon.ajaxMethod.Post, JSON.stringify({ task_id: 1312766152, title: 'Subtask' + new Date().getTime() }));
    })
    .then(function (subtask) {
        console.log('Created Subtask: ', subtask);
        //Retrieve the to-do again
        return wunderlistGetData(wunderlist.baseUrl + '/tasks/1312766152');
    })
    .then(function (newTodo) {
        //Will still print the old revision
        console.log('New Todo Revision: ' + newTodo.revision);
    });
}

We are currently introducing a delay of ~1 second to cope with that behavior, but that still seems very hacky. Could you check if there is the possibility to fix this?

Thanks Tobi

[duncan]

Hi Tobi,

The revision counts are asynchronous in our system—it's a side effect of our architectural decisions. And indeed, creating the revision increase locally wouldn't be good as you won't account for other changes made outside of your tool.

[duncan]

I hit "comment" too fast. In any case, if you're on a server, I'd recommend setting up a web hook listener and set a web hook notification on the list so that you can track the changes on your side. If you're in browser, then that's a bit trickier..

[tobiasviehweger]

Hi, thanks for the reply. Yes, we are indeed in a client scenario, so unfortunately WebHooks are not an option. I mean, it's not that big of a deal, since it's fixed with the next sync roundtrip, but it this specific part of our code bothers me for some time now :)

[duncan]

Totally understand. And yeah, you'll either get it on a sync, or you'll get a rejection if you try to update something with the wrong revision, but that's not the hottest user experience. I guess the best notification channel for you would be a web socket. We don't have any plans for that in our public API but I can definitely see the use case for it.