get_temporary_link returns empty json string some times

[jkane50]

Using php, I call list_folder to get a list of about 2000 files of about 800K each to download.

I then go into a loop calling get_temporary_link, retrieving the file contents and writing the file to local disk.

Out of 2000 requestes, about 3-5 times get_temporary_link will not return any json.  (empty string)

Retrying the call the get_temporary_link after trying all files have been tried once has so far always worked.

The files were uploaded long before my download request and no one other than the file sender who is done and myself has access to the files so I don't expect the files would be in use and any indexing should have been long done.

What could cause this random failure ?  Not always the same file. I dont see a pattern in which file will fail.  I also have not had any network/interent problems.

As development of the app continued, rather than write the files downloaded to local disk, I started uploading them to a sql blob.  Since doing that, which added a time delay over a local disk write, the failures of get_temporary_link have vanished.  This makes me think there is a maximum request rate and the blob write lowered by request rate under the maximum.

If there is a maximum rate at which get_temporary_link can be called or there is something else I should check, please let me know.

While retry has been effective and saving to blob vs local disk is effective, if there is something I'm missing, I'd like to code for it and not have the errors at all.

thanks!

[Greg-DB]

I'm not aware of any issues that should currently be causing /2/files/get_temporary_link to return an empty string. Can you print out the full raw request and response (including headers and body for both) for a sample of that so we can take a look? Just be sure to redact the access token. Feel free to open an API ticket if you'd prefer to share privately.

The Dropbox API does have a rate limiting system, but any call that gets rate limited by the system would receive an error response with a relevant error status code and an error message in the response body. Make sure you're checking the status code and response body for errors, and don't have your code assume the response body will be JSON unless indicated as such by the response's Content-Type header.

[jkane50]

I don't have a convenient way to trap sent or received headers.  If there is such a utility for a hosted environment (GoDaddy) please let me know.

My code works 99% of the time so it's an internet issue or metering issue.

Version 1 of my code was a feasibility study and I didnt add code to capture http response codes but have now.

If the errors continue to happen, I'll post again with that info.

I still would like to know the metered rate and code for it so if you have it, please provide!

[Greg-DB]

Thanks for following up. Please do let me know if you can reproduce and share information about that issue. I can't provide guidance on configuring third party environments such as GoDaddy though.

We don't have specific rate numbers documented for the rate limiting system; apps should be written to handle these rate limit responses automatically/dynamically based on the response. Also note that not all responses with a 429 or 503 status code indicate explicit rate limiting, but in any case that you get a response with 429 or 503 status code the best practice is to retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not. I recommend referring to the error documentation and Error Handling Guide for more information.