Drive API files.list以空项结果返回nextPageToken [英] Drive API files.list returning nextPageToken with empty item results

问题描述

在上周左右，我们在应用程序的文件列表中收到了用户缺少文件的报告。起初我们有点困惑，因为他们说他们只有几个文件与我们的查询字符串相匹配，但通过一些工作，我们可以通过向我们的Google Drive添加大量文件来重现问题。之前我们一直假设人们只有不到100个文件，并且没有进行分页以避免多个files.list请求。

切换到使用分页后，我们注意到在我们的一个测试帐户上发送了数百和数百个files.list请求，并且大多数响应不包含任何文件，但确实包含nextPageToken。我会尽快更新屏幕截图 - 但客户发送了足够的请求来加热计算机并迅速耗尽电池。

我们还发现根据查询的内容，即使它匹配相同的文件，它也会对检索我们的完整文件列表所需的请求数量产生严重影响。例如，在查询参数中将'='切换为'contains'会显着减少所做的请求数量，但我们没有看到任何保证这是一个合理的和一般化的解决方案。

这是预期的行为吗？有什么我们可以做的，以减少我们发送的请求数量吗？

我们使用以下代码来检索由我们的应用程序创建的文件，问题。

  runLoad：function（pageToken）
 {
 gapi.client.drive.files.list （
 {
'maxResults'：999，
'pageToken'：pageToken，
'q'：trashed = false and mimeType ='+ mime +'
}）。execute（function（results）
 {
 this.filePageRequests ++; 
 
 if（results.error ||！results.nextPageToken || this.filePageRequests> ; = MAX_FILE_PAGE_REQUESTS）
 {
 this.isLoading（false）; 
} 
 else 
 {
 this.runLoad（results.nextPageToken）; 
} 
} .bind（this））; 
 
  

解决方案

是的，正确的行为。

它通常在使用drive.file作用域时发生。 （我认为）发生的是API层获取所有文件，然后删除当前范围/查询之外的那些文件，并将其余部分返回给客户端应用程序。理论上，一个特定的文件页面可能没有范围内的文件，所以返回的数组是空的。

正如你所看到的，这是一种非常低效的方式这样做，但似乎是这样。你只需要继续关注下一页链接，直到它为空。

至于有什么我们可以做的，以减少我们的请求数量发送？

您已将最大结果设置为999，这是显而易见的一步。请注意，我已经看到这个值触发内部错误（超时？），它们表现为500错误。您可能想要牺牲效率的可靠性，并坚持100的默认值，这似乎是更好的测试。

我不知道您发布的代码是否是您的实际代码或简单的插图，但您需要确保处理401个错误（auth过期）和500个错误（有时可通过重试进行恢复）

In the last week or so we got a report of a user missing files in the file list in our app. We we're a bit confused at first because they said they only had a couple files that matched our query string, but with a bit of work we were able to reproduce their issue by adding a large number of files to our Google Drive. Previously we had been assuming people would have less than 100 files and hadn't been doing paging to avoid multiple files.list requests.

After switching to use paging, we noticed that on one of our test accounts was sending hundreds and hundreds of files.list requests and most of the responses did not contain any files but did contain a nextPageToken. I'll update as soon as I can get a screenshot - but the client was sending enough requests to heat the computer up and drain battery fairly quickly.

We also found that based on what the query is even though it matches the same files it can have a drastic effect of the number of requests needed to retrieve our full file list. For example, switching '=' to 'contains' in the query param significantly reduces the number of requests made, but we don't see any guarantee that this is a reasonable and generalizeable solution.

Is this the intended behavior? Is there anything we can do to reduce the number of requests that we are sending?

We're using the following code to retrieve files created by our app that is causing the issue.

runLoad: function(pageToken)
{
    gapi.client.drive.files.list(
    {
        'maxResults': 999,
        'pageToken': pageToken,
        'q': "trashed=false and mimeType='" + mime + "'"
    }).execute(function (results)
    {
        this.filePageRequests++;

        if (results.error || !results.nextPageToken || this.filePageRequests >= MAX_FILE_PAGE_REQUESTS)
        {
            this.isLoading(false);
        }
        else
        {
            this.runLoad(results.nextPageToken);
        }
    }.bind(this));
}

解决方案

It is, but probably shouldn't be, the correct behaviour.

It generally occurs when using the drive.file scope. What (I think) is happening is that the API layer is fetching all files, and then removing those that are outside of the current scope/query, and returning the remainder to your client app. In theory, a particular page of files could have no files in-scope, and so the returned array is empty.

As you've seen, it's a horribly inefficient way of doing it, but that seems to be the way it is. You simply have to keep following the next page link until it's null.

As to "Is there anything we can do to reduce the number of requests that we are sending?"

You're already setting max results to 999 which is the obvious step. Just be aware that I have seen this value trigger internal errors (timeouts?) which manifest themselves as 500 errors. You might want to sacrifice efficiency for reliability and stick to the default of 100 which seems to be better tested.

I don't know if the code you posted is your actual code, or just a simplified illustration, but you need to make sure you are dealing with 401 errors (auth expiry) and 500 errors (sometimes recoverable with a retry)

这篇关于Drive API files.list以空项结果返回nextPageToken的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！