I have an Android phone app prototype using the Google Drive public web link feature in order to sync a database sitting in said phone using a XML file.
For the last 3 weeks now, there have been 2 critical issues that have been cropping up, stability wise. I'll list them and tell you guys of my temporary patches to solve for this.
(1) Around March 27, 2014, When listing files with a Q filter set to specific parent IDs using the java API, with exponential back-off in the max. number of items per page AND exponential back-off for the timing in re-query in case of failure, as seen here: https://developers.google.com/drive/web/handle-errors: for some test sites, but not all (vast majority of Canadian sites were unaffected, and a very few US sites down south near NYC were also unaffected), this resulted in a 500 internal server error. Multiple patches were tried, among other things, to drastically slow down the rate of querying per user per minute, and the max query rate as set in the API console was also increased 10 fold. All of this to no avail. The final patch was to remove the multiple file list with a Q filter set with a given parent ID, and use children queries instead, in order to reconstruct a given tree of files inside of a user Google Drive. Now, the important thing to remember is that this code worked for 6 months straight, and failure occurrences started to be disseminated across test sites around the date mentioned above. One hypothesis I considered was perhaps that query with multiple parent ID filters did not work anymore. Anyone can correlate their own experiences with mine on this?
The Q string used was of the following format:
trashed = false and hidden = false and ('PARENTID1' in parents or 'PARENTID2' in parents or 'PARENTID3' in parents)
...where PARENTIDx are a given parent ID string. Note that this query string can contain up to 10 different parent IDs at once.
setMaxResults(...)
function was also called with a limitation of 1000 items, with back-off in case of failure downgrading this max count down to 100 in some cases.
(2) At April 22, 2014, 5:00 AM Eastern Time, the Google Drive Web folder across all test sites went awry. I have checked the timestamps of files uploaded to the Drive for some affected test sites, and the timestamps were updated correctly to the current time within a tolerance of about 2 minutes. However, fetching the XML file as a public link, shows that an outdated version from around April 22, 5:00AM or slightly before, is fetched instead. This is the first time I have seen this since we tested the Drive public web link feature continuously (from January 2014 onwards). I'd like the input of someone in the knows (possibly a Google engineer), who would be able to clarify this, if possible... In any case, damage control is now essential, so I'll have to either use the HTML Drive API to circumvent this problem, or just shift our whole database hosting strategy to another provider which offers better stability. Please advise...
(UPDATE FOR ITEM 2): it would appear that the timestamp of the file stored in the metadata is correct, but the contents of the file stays outdated, thus using HTML Drive API would be a moot point. Attempting to delete some critical files (moving to trash) triggers regeneration of the folder containing the .xml by the app, but it would appear that the content of the regenerated files stays outdated as well. Note that using the regular user interface to delete and upload files to Drive still works.
It would seem that the only way to re-establish proper Drive behavior is to completely delete the files in question, not merely moving them into trash.
(UPDATE FOR ITEM 2 AGAIN): I moved this question here: Google Drive API file update new possible bug
