1

We've been using the older version of the api for a while, which required explicit data push back and forth to drive. We ran into issues on app data restore when current users with lots of data tried to restore. It was an issue we couldn't reproduce locally, but we got a couple logs from people, and there was some kind of 500 error. In retrospect, it may have been a rate limit, as we were downloading lots of data in one chunk.

Anyway, moved to the new api tied to google play services. We let that handle app data, and use the api to handle data store and retrieval. In testing it seemed super smooth, and we didn't need to worry about backup explicitly, which sounds nice.

We're getting reports from users about missing data. I think I've finally replicated it. In a test account I've generated 1k-2k files. On the device where the data was generated, things are OK. On a new device, not all data shows up. In the log, I get this:

E/SyncScheduler﹕ Ignoring sync request: rate limited (on connection limit)

and...

E/SyncScheduler﹕ Ignoring sync request: rate limited (normal limit)

that. More of the latter.

Now that its going through play services, its kind of a black box. The status from the call seems to be SUCCESS, but the call to drive (remote) is clearly failing.

Is there a per-user daily type of limit? If play services is dealing with drive directly, is there a way to figure out that we're over the limit? Right now, it just looks like the user has lost their data, but the app thinks everything is OK. Ideally the user rate limits could be raised, or somebody can tell me what we're doing wrong. We're currently in a minor nightmare situation with customer support.

Kevin Galligan
  • 16,159
  • 5
  • 42
  • 62
  • I myself was having a lot of unexplained data losses with GDAA (the new API), only to see the files again later (hours, days). It was in the early days of GDAA (Jan - May 2014). I dropped it and returned to the REST Api, since the 'black box' with latency issues was just too hard to manage considering there was also SyncService and GCM involved. – seanpj Jul 07 '15 at 11:13
  • @seanpj We're debating the same. Its been pretty bad over the last couple weeks after we released. – Kevin Galligan Jul 07 '15 at 14:11
  • The winner (so far) is [this one](http://stackoverflow.com/questions/30172915/user-disconnecting-app-in-drive-causes-loss-of-data-under-file-scope). Unfortunately, applies to both the GDAA and the REST. At least under REST, you have a fighting chance with the DRIVE_FILE scope. – seanpj Jul 07 '15 at 19:28

1 Answers1

3

The issue is not caused by rate limiting but due to a bug that can occur when a user has thousands of files. We are working on a fix and you can follow the issue here https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3905

Thanks for the report.

Ofir
  • 110
  • 3
  • Is there any way to verify that the issue we're having is the same one that you're working on? I'd like to be totally sure we're telling these people true statements. – Kevin Galligan Jul 08 '15 at 15:04