Steps to reproduce highly welcome.

1 - Sign in to Google via gnome-online-accounts and grant GNOME full access
2 - open gnome-todo
3 - Add a task to the gmail task list
4 - navigate through a browser to https://mail.google.com/tasks/canvas
5 - Mark the task you entered through gnome-tasks as complete
6 - Add several tasks
7 - Check a 3rd party app to make sure that it's syncing properly
8 - open gnome-todo and notice that the task you initially entered is not marked as complete and the several other tasks you have entered are also not there
9 - Add another task from gnome-todo
10 - Check https://mail.google.com/tasks/canvas  and 3rd party sync app and notice that the task added from gnome-todo and those added directly via web are there
11 - open Evolution and navigate to Tasks tab and notice that it has the same exact content as gnome-todo

NB: tasks that already existed before the initial sync are not downloaded to gnome-todo either

Thanks for a bug report and steps. Both gnome-todo and evolution are using the evolution-calendar-factory, which is provided by the evolution-data-server (eds), thus they share the same data. As far as I know, there is no good checking for changes implemented on the eds side, thus all the updates are done either manually, of periodically. You can set the refresh interval in the Properties of the task list (it can be found in the context menu of the task list). The same menu also offers a 'Refresh' item, which is used to initiate the refresh manually.

That you do not see older tasks is weird. Maybe the initial update (check of available tasks) failed for some reason, or had been just stopped earlier). I cannot test it right now, due to "Daily Limit Exceeded" error returned by the Task List.

I retried this and once the "Daily Limit Exceeded" error is gone the Tasks work just as expected with respect of the update itself.

I also discarded my local cache and before that entered more than 100 tasks to the task list, when I realized that there are downloaded only the latest 100 tasks currently. I'll fix it.

After some investigation, the problem is that the Google server changed something and defaults to max 100 results when "too large" number is used. The GTasks service implements a very different pagination, which is not covered in the current libgdata. I filled a bug #775813 for the libgdata part.

I made this work with the changes proposed in the bug #775813, but please note that they are unreleased yet (even not approved), thus the evolution-data-server tests in the build time whether it can use the code and when it's not available, then it fallbacks to the old behaviour. That also means that it's not enough to get a newer libgdata, but the evolution-data-server should be rebuilt against that newer libgdata, to take the changes into effect, because it's determined in the configure time whether the new code can be used or not.

Created commit f87e020 in eds master (3.23.3+)
Created commit abe0188 in eds gnome-3-22 (3.22.3+)

Thank you for the amazingly fast support and continued contributions to the fantastic GNOME stack.

*** Bug 777573 has been marked as a duplicate of this bug. ***

I'm reopening this, because the change in bug #775813 was not accepted (the changes I committed, see comment #6, require those changes proposed in bug #775813). It means that this will be re-done once the libgdata bits are finished.

I updated the eds changes according to libgdata bits and I also made it smart enough to fetch the cache automatically when eds is built against patched libgdata, thus the tasks will appear without any special intervention by the user. And as I made a mistake it's divided into two commits:

Created commit afdb2bc in eds master (3.23.91+)
Created commit 4f797ae in eds master (3.23.91+)

Created commit 682e275 in eds gnome-3-22 (3.22.6+)
Created commit e3c177c in eds gnome-3-22 (3.22.6+)