list_folder with include_media_info=true return empty entries array.

[Digitalhappy]

When calling /2/files/list_folder with include_media_info = true the API is returning an empty set on a folder that I know contains files.  I can see the files in the Dropbox website and also in my desktop dropbox.

If I call /2/files/list_folder with include_media_info = false I get the listing of all the files in the folder as I expect.

I noticed the issue in my application today and can see the same behaviour when using the API Explorer.  My application is built around using this media info so I am certain that the same calls were working previously.

[Greg-DB]

When you set include_media_info=true, files will not be returned until their media information is available. The media information for files isn't always immediately available though, so you can get missing file entries like this. They will get listed once the information is available, but this can take a variable amount of time, especially if there are many files or a lot of activity in the account.

[Digitalhappy]

Thanks for the clarification.  

It would be helpful if that was explained clearly in the documentation.
I have to say that I think this is a very poor way for the API to respond in this case.

I understand that the media info might not exist yet.

That's fine. I appreciate that it could take time to generate.

However I think it is very misleading to return an empty entries array.  That indicates that the folder is empty when it is clearly not true.  That leaves my application thinking that this folder is empty and that there is nothing to see or do in this folder which is clearly not the case.  

Would it not make more sense to return a normal listing dataset containing the same entries as would be returned if include_media_info=false but include something to indicate that the media_info is pending.

You could return something like this;

"entries": [
  {
    ".tag": "file",
    "name": "myphoto.jpg",
    "path_lower": "/mypath/myphoto.jpg",
    "path_display": "/mypath/myphoto.jpg",
    "parent_shared_folder_id": "1234567890",
    "id": "id:abcdefghijklmn",
    "client_modified": "2015-09-30T09:08:43Z",
    "server_modified": "2017-02-28T15:15:33Z",
    "rev": "1234567890",
    "size": 5685499,
    "media_info": null,
    "sharing_info": {
      "read_only": false,
      "parent_shared_folder_id": "1234567890",
      "modified_by": "dbid:abcdefghijklmno"
    },
    "content_hash": "1234567890abcdefghijklmno"
  }
]

At least that way my application can decide how to proceed.  

I could flag files with media_info=null for later processing or I could download the images that are missing media_info and generate it myself.

[Greg-DB]

Thanks for the feedback! I'm passing it along.

[rustoiy]

I encountered another side effect here, which seems like more of a bug-
On calling /2/files/list_folder on a folder containing a large number of files, (i.e. requiring pagination in the API response) the API was responding not only with an empty list, but with has_more set to true.
This was found to be because no files in that folder had metadata available yet.

Unfortunately this is annoying to reproduce on my end and I didn't capture where the 'cursor' field was pointing, but it resulted in the call recurring infinitely .

[Greg-DB]

Thanks for the report @rustoiy. That does sound like unexpected behavior. If you can share a few responses showing that empty entries list, including the has_more=true and cursor, that would be helpful for us to investigate. (You can share privately here if you'd prefer: https://www.dropbox.com/developers/contact )