Google Drive push notifications - google-drive-api

I'd like to use the /watch (doc) API endpoint for subscribing a remote url to receive informations about changes in Google Drive.
The webhook received doesn't contain any body as specified in the documentation but contains headers which should help to understand what happened on the user's account.
Problem is that the headers doesn't contain anything useful and contains incorrect values too.
I'm saving a pageToken that I'm using to retrieve changes but when receiving multiple concurrent requests there's an high risk to receive the same change twice.
Is there a safe way to understand what happened hook by hook?

Related

What is ErrorMessagePerFolderCountReceiveQuotaExceeded?

I'm synchronizing Office 365 mail folders via the Office 365 REST API by doing a GET on me/MailFolders/{folder_id}/messages. For two different accounts, I've recently been getting 500 responses to these GETs with the error code ErrorMessagePerFolderCountReceiveQuotaExceeded and error message "The number of received messages has exeeded the quota for the folder." (Typo theirs, not mine.)
I can't find any documentation on this error. What does it mean? What should I do to fix this situation?
I couldn't seem to find any documentation for it either.
From the error message, it seems it might be related to the "Maximum number of messages per mailbox folder" limit on Exchange Online. Do you know if the folder contains 1M+ messages?
https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#MailboxFolderLimits
I guess my other idea would be that you're getting too many messages in too short of a time period. Suggestion would be to use the endpoint GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages with $deltaToken and $skipToken to skip previously synced messages.
https://msdn.microsoft.com/en-us/office/office365/api/mail-rest-operations#synchronize-messages
When you do a sync to an Exchange folder via the Outlook REST API, you pass it a sync token. In response, the API returns a new sync token and a set of changes. And the client is expected to send the new token back with their next sync request.
With most systems that support sync, using a stale sync token (i.e. one that has been sent to the server once) in a subsequent request will generally just succeed with no problems. And Exchange appears to work like that... for the first 999,999 times you do it. On the 1,000,000th time (and each time thereafter), you get ErrorMessagePerFolderCountReceiveQuotaExceeded. This is (I think) because Exchange keeps track of each token that it's given out and updates the token in its store each time it's used for sync. If a client uses a stale token, Exchange views it as a new client and adds that stale token as a new entry in its list of active tokens. That active token list can have at most 1,000,000 entries. ErrorMessagePerFolderCountReceiveQuotaExceeded is the cryptic error indicating that Exchange's active token list has overflowed.

When creating a push notification channel using the Google Drive API (v3) does setting payload to true in the request body do anything?

I would like to receive metadata or a summary of changes in my push notifications from the Google Drive API.
It would appear from the documentation that setting payload to true in the request body would accomplish this. As far as I can see, both file and change notifications do not include a request body even when payload is set to true when the notification channel is created.
The documentation states that payload is "A Boolean value to indicate whether payload is wanted. Optional."
Does anyone have any idea what this field does (if anything) and whether there is a way to include additional information?
If we check with other Google APIs with similar payload request usage, it looks like a flag to determine if the message body should be included in the notifications.
Take a look at the Google Admin SDK Push Notification, its almost similar with Drive API push notification is doing.

Drive push messages - spammed by notifications

I am currently developing system synchronizing files between Google Drive and external storage. I am trying to process push notifications. I was already able to register for them and receive them. After receiving each notification, I acquire list of changes using proper endpoint and try to get a new version of file if necessary, so the flow is like that:
Subscribe to notifications using changes.watch
Receive some push message with url to changes
Use API with provided query to get changes on changes.list endpoint
Filter items that changed after particular moment
Get content of file and transfer it to another service
It seems that after initial notify message, Google starts spamming a new one, always after getting file. I suspect that the action of getting file content is changing some timestamp on file and therefore - its content is changed.
Is it possible not to modify file in any way when getting its content?
EDIT:
It seems that this behaviour concerns files.export endpoint as well - Exporting Google Doc as PDF leads to notifications spam too. Commenting out export part in a code stops them from coming.
You're getting spammed since Changes: watch listens more to changes made by a user, not the file itself.
What you need to use in this scenario is Files: watch. It subscribes you to listen to changes to the file itself.

Google Drive API webhook returning change resources in wrong order

I have a webhook setup with the Google Drive API, and it works for almost everything except when a file is deleted. It seems as though I always get 2/3 webhook notifications when a file changes, which isn't a problem.
When I delete a file however, those 2 notifications mess things up. They come out of order (i.e. change resource 989 comes before 999), and the new one comes first, invalidating the older change resource.
To explain, here are two post I received on my webhook, chronologically ordered.
This one has a good webhook, but the resource id in the param is 899.
http://i.stack.imgur.com/il3co.png
Now this one comes in after, which is has a param of 898, but I cannot use.
http://i.imgur.com/ZLwUC1Z.png
This last one most likely has the delete call I need, but cannot access.
Is this something I have to handle? Or is it something from google's side in terms of async calls?

Google Drive API says some files do not exist when in fact they do

So, I've gotten to the point in my app where I can retrieve a list of spreadsheet documents from a user's Google Drive account by using the Google Spreadsheet API. I populate the file list in a ui control that users can click on to then retrieve the list of its worksheets. It's working as expected in some cases, but in others it is not. In my request, I use the url that comes back from the file list, and even so, the API responds with:
Sorry, the file you have requested does not exist.
Make sure that you have the correct URL and that the owner of the file hasn't deleted it.
Well, surely the file wasn't deleted. I got it back in the response to my request for the files list. I also can get to the file via a normal web browser. Also, the URL is correct because that's the one the API responded with. My code does not manipulate the url that comes back in that initial files response. In fact, here is the URL that is used to grab the worksheets:
https://spreadsheets.google.com/feeds/worksheets/{long key here}/private/full
So, my question is why does my request for some worksheets come back with a response with the actual list of worksheets, but on others (which I have access to, and I know exists) I get the faulty response.
Thanks,
Arie
My app is using OAuth 2.0 and I ran into the same error with new Google Sheets. What fixed that was making a change in scope param sent during OAuth's authorize call and then reauthorising (reinitiating OAuth flow and obtaining new tokens).
Until now scope in my app was just:
https://spreadsheets.google.com/feeds
Updated scope and solution to the issue in my case:
https://spreadsheets.google.com/feeds https://docs.google.com/feeds
I'm running into this in my own stuff. At least for what I'm running into, it seems to be an issue with New Sheets. I'm sorry to not have more of a solution (I'm still trying to find out what to fix on my end) but this may help you narrow down the issue.