API Fixes: Real Retry-After Values and Keys for Updating Buckets
A rate-limited request now tells you how long to wait, and an access key can be created or edited for a bucket whose policy is being applied.
What's changed
- A 429 response now carries the real number of seconds to wait, in the Retry-After header and in retry_after in the body. Both said 0 before, so a client that obeyed them retried at once and was refused again; a client that waits the stated time is now let in
- Creating or editing an access key for a bucket that is being updated no longer fails. The API answered 422 saying the bucket does not belong to your team, a key could not be edited at all while one of its buckets was being updated, and the console's bucket picker left such a bucket out
- Saving a bucket policy leaves its bucket updating for a few seconds, so a script that gives a key a folder and then creates the next key for the same bucket ran into this