应用错误收集

我们的应用程序需要用户文件和文件夹的完整列表。我们通过files.list()库使用Javascript（基本上与官方API reference中显示的代码相同）。

我们使用“drive.files”范围。

检查对列表的响应，我们发现一些文件总是丢失。我做了各种测试来理解这个问题：

文件显然存在。它们显示在Google Drive Webapp中，如果我通过ID明确请求它们，我可以通过API获得它们而不会出现问题。
它是可重现的，总是缺少相同的文件。
这不是短暂的。我试了一天后仍然缺少相同的文件。我知道API中的一些奇怪的效果会在一段时间之后消失，但不是这个。
这不是一次性的事情（例如在上传过程中出现了一些奇怪的事情）。如果我再次使用完全不同的Google帐户，则会丢失文件。 files.list调用错过了一个测试4中的一小部分147个上传文件，而另一个帐户中的相同147个文件的另一个测试中缺少23个文件。
仅在我使用drive.files范围时才会发生。如果我将范围放宽到drive，则返回所有文件。如果查看Google云端硬盘Web应用程序中的“详细信息”，则丢失的文件将显示为由我们的应用程序创建。因此，他们似乎并没有以某种方式失去原点。
当我指定搜索查询时也会发生这种情况。如果我使用搜索词“q：modifiedDate＆gt;'2012-06-04T12：00：00'”调用files.list，它也应该返回所有文件，则缺少相同的文件。
我重新实现了与API的纯REST调用相同的事情，以排除它是Javascript库的问题。错误仍然存在。

更新：我可以将其跟踪到分页和maxResults参数的问题。如果我使用不同的值，API会返回不同数量的项目：

maxResults=100我得到100 + 100 + 7 = 207。

使用maxResults=99我得到99 + 99 + 28 = 226。

maxResults=101我得到101 + 101 + 0 = 202。

最后的结果很有趣，它给了我一个nextLink，表明有更多的结果，但最后一个响应中的items数组实际上是空的。仅这一点可能表明存在错误。

但是，这只发生在drive.file范围内，计数在完整drive范围内是一致的。

我很高兴听到解决方法的想法。我知道跟踪用户文件的其他方法，例如：使用更改Feed。我已经使用了它，但是对于我们应用程序中的特定部分，我只需要在用户帐户中提供所有应用程序项目的可靠且完整的列表。

还有一点需要注意：我们之前的“drive.files”范围还有其他问题（请参阅Listing files with search query returns out-of-scope results (drive.files.list call, using drive.files scope)）。事实证明这是一个简单的解决方案。也许这个问题是相关的。