Open tobiasviehweger opened 8 years ago
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.
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..
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 :)
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.
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:
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