IssueTracker

It seems you should use com.intellij.psi.PsiClass.getSuperClassType() to check

@Google: I have found out what causes the stale data to be returned. Please rename the issue to "Tasks API does not update "updated" field and "ETag" when a task is modified". Because the problem is that when requesting data from https://www.googleapis.com/tasks/v1/lists/tasklist/tasks systems that have a http cache (like iOS) will first check if the data has changed by loading the ETag. If the ETag has not changed then the cached version of that website is returned.

Longer explanation:
I was able to reproduce and examine the problem now. I changed a task on http://calendar.google.com and loaded the task lists using the API Explorer on https://developers.google.com/tasks/v1/reference/tasklists/list . The "updated" date of the task list did not change, which is the bug I reported in my first post here. I have tried it several times but the "updated" date did not change. My workaround for this is to ignore it and always sync all task lists.

However as I reported in post #2 some users got stale data, even when reloading all tasks. It turns out that the reason for this is that your server returns

Cache-Control: private, max-age=0, must-revalidate, no-transform
ETag: "8MEupY6AVkDup3m0O6mGjMTpTY8/MzgxNjkyNzQy"

for the URL https://www.googleapis.com/tasks/v1/lists/tasklist/tasks (i.e. for loading all tasks of a task list). That means that the ETag can be used to determine if the contents of the page have changed. However the problem is that the ETag does not change when the contents change (i.e. when a task in that list has been changed). Thus systems with a http cache (like iOS) will return a cached copy of the https request, instead of loading the data. That means that my app will get stale data, because it gets a previously cached copy of the request, because the ETag of the page hasn't changed. A workaround is to disable the cache in iOS when loading the data.

So this all seems to be caused by the same bug, which is that changing a task in a task list does not update the "updated" date and the ETag of the task list and of the request that loads all tasks of the list.

Please tell me if you have any questions. Thank you very much!

I am experiencing this same exact problem.  I can change a Google Task in the Google Tasks app on my iOS device (iPhone, iPad).  The updated task appears correctly in that Google Tasks app and via Google's website interface (Calendar/Tasks sidebar and E-mail/Tasks sidebar).  However, when another app (CalenGoo) on my iOS devices syncs the Google Tasks it fails to get the updated task but rather re-displays the older (pre-update) task.  

This problem is especially irksome when what I changed is the task's date (say from August 5 to August 12).  It shows as updated in the Google Task app on my iOS devices and the Google website interface to tasks.  However, after the other app (CalenGoo running on my iOS devices) syncs via Google's API, the task's date is still the old one (August 5); so, the task displays on the incorrect date in CalenGoo's graphical user interface.

Please escalate the priority to address this irksome issue.

Tony    

I can confirm that the latest CalenGoo (1.5.71) successfully works around the bug in the Tasks API for me.  But, it comes at the cost of forcing a complete download at every sync.  Please fix this, Google.  

I am experiencing the same issue via both an Outlook sync plug-in as well an iOS app. Please fix this!

BTW, I should mention a workaround I found -- perhaps it will help with the Outlook sync.

Add or delete a task when you need to ensure a good sync.  Changing the name or due date of a task doesn't trigger a refresh, but adding or deleting a task does every time.  For me, anyway.

I added a junk task like "fsfsfsfsfsfsdfhfgh" when I needed a good sync.  Next time I needed a good sync, I deleted the junk task.  Shampoo, rinse, repeat.  

Same bug here. Any news about this issue ?

I've been experiencing that issue for quite some time as well unfortunately.  At the moment, I've built in a workaround along the lines of the comment in #12.  It's far from ideal and there's an overhead to having to create/delete a temporary task to just force a good sync, but I haven't found any other solution.

To the comment #14 author: the workaround that the developer of CalenGoo (the threadstarter author) implemented is working perfectly for me w/ no noticeable overhead.  

When you refer to overhead, do you mean a manual process that you perform in an app's UI or programmatical via the API?  If the latter, perhaps the CalenGoo developer would be willing to document his workaround if you ask!  His product tech support is outstanding.  [Assuming that this note listed above in comment #8 isn't the whole fix -- it might be: "A workaround is to disable the cache in iOS when loading the data."]

Just ignoring the Updated field (as suggested in the original post) didn't work for me unfortunately.  The problem I'm seeing is more along the lines of the comment in #2; i.e. the actual payload of the Tasks is outdated following an update.  What was explained in #8 (ETag not changed) might explain what's going on in my case as well.  I'm not a iOS app; my app is a browser extension so disabling cache isn't an option for me.

The overhead is programmatical and really just the unnecessary API call being made to force a good update.

Excellent.  So, "annoying because you have to do a workaround API call" as opposed to "annoying because it noticeably slows down the user experience."

I also have this bug. Like the comment #12 I have to create & delete a temporary task to have a good synchronization.
Can someone at Google look to fix this bug please ?

I'm having the same problem and it affects Calengoo, which is an excellent app I rely on for several things in my life and work. The workaround found by the developer (i.e. forcing a complete sync rather than syncing only the modified lists) works but the task syncing is obviously too slow. Also the trick of creating a dummy event to force the syncronization works but it obviously does not have an impact on auto-sync.
Google please solve!

I am also seeing this issue when using CalenGoo to synchronise Google Tasks.  I too am using the workaround suggested by the developer but a permanent fix is required.

I have about 150 tasks and don't notice any appreciable overhead ever on WiFi or LTE.

To be clear: the manual workaround fix I suggested above (forcing a resync by adding a junk task for sync1, deleting the junk task for sync 2, adding .. ...) is now only for non-CalenGoo users.  The developer's fix on 8/3/19 works fine on my old iPhone 7, and I don't know why any CalenGoo user would have to use my manual workaround?

There is no "workaround suggested by the developer" that someone can use for CalenGoo -- he fixed it in the code.  Unless you are on a very slow connection or have way more than my 150 tasks, I can't think of any reason why this bug would be causing you problems in CalenGoo?  

So, to recap: I have about 150 tasks and 11 calendars.  A full CalenGoo resync never lasts more than 3-5 seconds. Is your experience different?  

The issue still persists. When a task is created or deleted in a task list, the etag of the task list changes.
If a task is edited (e.g., the title), then the etag of the task list does not change.