GNOME Bugzilla – Bug 785952
Google Tasks refresh fails with Bad Request
Last modified: 2017-08-24 09:23:52 UTC
Versions: ------------ evolution: 3.24.4 evolution-data-server: 3.24.4 libgdata: 0.17.8 How to reproduce: -------------------- 1. Add google task from evolution. Authorize it 2. Default task lists appears with all tasks listed. 3. Create a new task from web. 4. On evolution, select task list, right click, select refresh. Actual behavior: Nothing happens. Changes do not sync back from google. More Info: -------------- 1. Close evolution 2. Delete local cache (~/.cache/evolution/task/<uid>). Restart evolution. 3. Now it syncs back all the pending changes from google. Libgdata: --------------- I created a simple app uses libgdata api to create/update google tasks. And it works, also according to https://abi-laboratory.pro/tracker/timeline/libgdata/ 0.17.8 has 100 % backward compatibility. So I am not filing this against libgdata, (but I could be wrong!) Summary: ------------------- evolution --> google task (works!) google-task --> evolution (doesn't work)
Thanks for a bug report. I enabled libgdata debugging and the problem is that evolution-data-server invokes on refresh such query: GET /tasks/v1/lists/xxx/tasks?updated-min=2017-04-20T17:48:04Z& max-results=100&maxResults=100& updatedMin=2017-04-20T17:48:04.000001+00:00& showCompleted=true&showDeleted=true&showHidden=true to which the server responses: HTTP/1.1 400 Bad Request ... Content-Type: application/json; charset=UTF-8 ... { "error": { "errors": [ { "domain": "global", "reason": "badRequest", "message": "Bad Request" } ], "code": 400, "message": "Bad Request" } } I already tried to address this on the evolution-data-server side with this commit: https://git.gnome.org/browse/evolution-data-server/commit/?id=c2947758f27 which had been only for the Google address book, not for the Google Tasks. I'll do something similar for it too.
Created commit a6caed3 in eds master (3.25.92+)
This deserves further investigation rather than a workaround, as there could be an underlying bug in libgdata still. If this was done with libgdata 0.17.8, then it was done with commit https://git.gnome.org/browse/libgdata/commit/?id=684f95e8845be4f9efc434ea6456bee99b2303ac, which touches this code. That probably means that Google have changed how their servers work again. Khurshid, with the libgdata app you wrote, did you set the updated-min property on the GDataQuery you made? (See also, bug #780067.)
I just tested with libgdata’s command-line Tasks client (modified to set gdata_query_set_updated_min()) and it looks like Google have changed their server behaviour again. I think I’ve fixed it with this libgdata commit: commit 0851328783fda2afccc35a034301d54a2a00b36b (HEAD -> master, origin/master, origin/HEAD) Author: Philip Withnall <withnall@endlessm.com> Date: Wed Aug 23 10:26:15 2017 +0100 Revert "tasks: Re-add ISO 8601 formatting workaround for Tasks service" This reverts commit d10155034b0fa2e43e2889e55157798ce073f807. It looks like Google may now have fixed the timezone formatting bug in their Tasks services (they had previously fixed it in their other services; see bug #780067). https://bugzilla.gnome.org/show_bug.cgi?id=785952
@Philip No. I didn't. And it doesn't work with "updated-min". Btw, why we are building query with "updated-min" + "updatedMin"? According to https://developers.google.com/google-apps/tasks/v1/reference/tasks/list, only "updatedMin" is supported.
(In reply to Khurshid Alam from comment #5) > @Philip > > No. I didn't. And it doesn't work with "updated-min". Does it work if you apply commit 0851328783fda from libgdata master? > Btw, why we are building query with "updated-min" + "updatedMin"? According > to https://developers.google.com/google-apps/tasks/v1/reference/tasks/list, > > only "updatedMin" is supported. Legacy reasons. Refactoring the code to remove the redundant updated-min parameter is more effort than it’s worth. It does no harm.
> Does it work if you apply commit 0851328783fda from libgdata master? Yes. Now it works for both tasks and contacts. (But I didn't test against eds-3.25.92 with Milan's patch). Thanks.
Great, thanks for re-testing it.
(In reply to Philip Withnall from comment #3) > This deserves further investigation rather than a workaround Right, that's why I added you into the loop. The change in eds is to not malfunction when users use different (older/unpatched) libgdata, and even for cases when Google decides to change the time format again. Thus it may look like a workaround, but it's a safety code to keep running in cases which are out of our hands.
(In reply to Milan Crha from comment #9) > (In reply to Philip Withnall from comment #3) > > This deserves further investigation rather than a workaround > > Right, that's why I added you into the loop. The change in eds is to not > malfunction when users use different (older/unpatched) libgdata, and even > for cases when Google decides to change the time format again. Thus it may > look like a workaround, but it's a safety code to keep running in cases > which are out of our hands. Good plan, thanks.