Google Drive SDK Push Notifications, receiving wrong changes id

8
votes

When I subscribe to all changes of my Drive account, sometimes I receive changes with wrong id. According to my observations changes of specific file are aggregated in last change with some time period.

For example: If I change file in my drive and if I have received 3 notifications with ids: "#21, #22, #23", I expected that I can get change of "#23", if there is no more changes to that file. But sometimes I receive last change with id greater than it exists. When I use API changes list, I get lastlargestChangeId = receivedChangesId - 1.

I have tested it with google examples and I get the same results:

push notifications test

{"notification_id": "xxxxxxxxxxx", "resource_state": "change", "expiration": "Mon, 07 Jul 2014 13:58:37 GMT", "self_link": "https://www.googleapis.com/drive/v2/changes/3387"}

{ "kind": "drive#changeList", "etag": "xxxxxxxxxxx", "selfLink": ".../changes?startChangeId=3340", "largestChangeId": "3386", "items": [ ... ] }

Am I wrong?

2
push-notificationgoogle-drive-api
I'm running into this exact problem. When I "remove" (not delete) a file in drive, I get a notification with a changeID. Doing a "getChange( changeID ) returns a 404, but when I check the "getLargestChangeID", I find that the changeID that I was given by the notification is one digit larger than what the largest change ID really is. Can someone explain this please? - Stanley
Same here, looks like a bug... When I upload a new file, I receive a change notification, the provided id is incorrect. But the id - 1 is OK. - Vico
If it can help, on upload I also receive "change" for the x-goog-resource-state, and no "add" at all. - Vico

2 Answers

3
votes

It seems that Google categorized it as a bug: https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3706

Star it so Google can prioritize it.

1
votes

Here is the official answer:

After talking with our engineers, this actually is working as intended. The change ID given in the push notification (the ID and the self link that contains that same ID) remain valid only as long as there are no newer changes on a particular resource. Take the following example scenario on a user's drive with push notifications being sent for all changes. 1) Resource A (a file or folder, etc) changes. 2) Drive API sends a push notification with a change ID (example 1234). 3) This change ID (and the selflink) can be used now to successfully pull up the change. 4) Resource A changes again. 5) Drive API sends a push notification with change ID 1235. Note that change IDs are monotonically increasing. 6) Accessing the earlier change ID (1234) through a changes.get or the self link will 404 now because there is a newer change on the same resource. 7) You can still access change ID 1235 here.

In general, you should not expect to be able to get a particular change ID with changes.get. Any resource is only in the changes stream once. So as soon as the resource has a newer change, the old change ID is invalid. Some commenters have noted that you can do changeID - 1 to get this change. However, this will not always work. In my testing, I have gotten a 404 on both the change ID and for change ID - 1. Instead, you should sync a given set of resources and note the largest change ID of that set. Then, when you get push notifications in the future, see if the change ID you get in the push notification is newer than the largest you stored. If so, use changes.list in order to get all of the resource changes between the last change ID you have seen / stored and the one you just received.

tldr; Do not count on change IDs existing with changes.get. Use changes.list instead to get all changes from a base change ID to the change ID you get in the push notification.

https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3706