Child Item

e2e testing with the software using the dropbox API

We're using Dropbox API for a small integration software. So far, the software was doing good. We thought about testing the system and added e2e test cases for the software. When these tests run daily or more often on the CI, we now facing:

Error: Error while deleting directory.
Directory: 'test-folder'
Status: '429'
Message: 'Request failed with status code 429'
Response: {
  "error_summary": "too_many_write_operations/",
  "error": {
    "reason": {
      ".tag": "too_many_write_operations"
    }
  }
}

The problem is legit as we're testing against a real Dropbox server.

Our concern was, can we configure our account to increase the write operation timeouts?

Or is there any mechanism to spin up a testing Dropbox server just for the testing purpose?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

If there are multiple changes at the same time in the same account or shared folder, you can run in to this 'too_many_write_operations' error, which is "lock contention". That's not explicit rate limiting and can't be increased or removed; it's a result of how Dropbox works on the back-end. This is a technical inability to make a modification in the account or shared folder at the time of the API call. This applies to all account types. You can register another account, but that account would also be subject to lock contention.

This error indicates that there was simultaneous activity in the account or shared/team folder preventing your app from making the state-modifying call (e.g., adding, editing, moving, copying, sharing, or deleting files/folders) it is attempting. The simultaneous activity could be coming from your app itself, or elsewhere, e.g., from the user's desktop client. It can come from the same user, or another member of a shared folder. You can find more information about lock contention and optimizations you can make here. The app will need to be written to automatically handle this error.

In short, to avoid this error, you should avoid making multiple concurrent state modifications and use batch endpoints where possible. That won't guarantee that you won't run in to this error though, as contention can still come from other sources, so you should also implement error handling and automatic retrying as needed.

I recommend referring to the error documentation and Error Handling Guide for more information.