Google Drive API webhook returning change resources in wrong order - google-drive-api

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?

Related

How to not detect opening of files and folders in google drive changes api

I am building an expressjs application using the google drive api that notifies the user whenever there is a file change in their google drive through webhooks. However, i am also receiving webhooks when i open/view a folder or a file, which is completely unnecessary. Is it possible to only receive webhooks whenever a new file is created or deleted in the drive? And if so, how do i do it?
There is no direct way unfortunately.
You will likely have to make another request once your app has been notified of a change. Its possible you may have to persist some data to compare with depending on what you need to do exactly. The watch endpoint, as you have seen, will notify you of almost every change, including views. So you'll need to find a way to filter these out.
If you are trying to get create/deleted times only then I would suggest taking the file id from the change notification and making a request to get the file metadata and seeing if the file was created in the last 5 minutes (or less) for example. You can speed this up by only getting the createdTime field for instance.
For deleted, you can either get the type of change directly from the change notification, but this will only notify you if you have deleted it permanently i.e. not in the trash. Trash events look just the same as the others. If you need trash notifications, it is going to be more complicated. There is a trashed attribute, but not a timestamp for it. If you need this then you will probably have to keep a snapshot of which files are trashed and then every time you get a request, check to see if the file that changed is now trashed.
There is an active feature request for this
Support event type filtering for Changes watch channel
Go and give it a ☆ to let Google know that you want this feature!

Google Drive push notifications

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?

Get list of deleted onenote notebooks/sections/pages

My appplication periodically sync data with Onenote. If some content is deleted after syncing for the first how I can get list of names of pages/sections/notebooks that are deleted. Currently I am comparing id's of pages/sections/notebooks that are present in my system and one the which I receive from onenote syncing everytime. But this process takes too long and specially if I have large data.
Is there any MS-Graph/OneNote API which can provide me list(id's) of these deleted entities ?
There's no API to retrieve the list of deleted entities, unfortunately. The best way you can achieve this today with the API is to set up webhook integration, keep state on your side and the querying when you receive a webhook notification saying something changed - it looks like you're doing something similar.
If you believe the API should have this functionality, I encourage you to create and upvote an item in uservoice:
https://onenote.uservoice.com/forums/245490-onenote-developer-apis

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.

Google Drive SDK, How to check if a file has been shared outside of the domain by using Permission feed

I am using Google Drive SDK for .NET. Everything is working as expected, except that whenever I get the permission feed for a particular document. I get the Id, kind, name, role, selflink and type fields on permission.
There is no mention of the email address of the user which is stopping me from recognizing by reading the permissions, whether a file has been shared inside the domain or outside of the domain.
I can't use Google Docs API to get the ACL on doc because I am writing an app for users over 200000 users and I will need speed which is provided by Google API Console.
What should I do?
Thanks
You can use the Documents List API to get the email addresses. I'm curious why you believe Drive is faster than Documents List, for most API calls they have a comparable response time.
https://developers.google.com/google-apps/documents-list/#retrieving_the_acl_for_a_document_file_or_collection
Thanks for the idea but can I use Document List API with the Service Accounts provided through API Console?
Why do I believe that Google Drive SDK is better? Because we don't have any control over Document List API where we can set QPS (Query per second) limits or not that I know of.
Secondly, with Document List API when you make request to servers, in the past I had to create a fault tollerent algorithm in such a way that if one request fails second should go after 2 seconds if that fails then make your next request after 5 seconds until 7 second delay.
So, I don't think that Document List API would be a good fit for processing documents over 200000 users everyday unless Google has changed the way their API used to behave?