When using the Cosmos DB Studio, it is possible to encounter transient errors, and the application cannot handle such errors (like 503 Server Busy) now. When the transient error happens, the application would even have an inconsistent view with the real service. For instance, if a database deletion request (use the SDK API DeleteAsync to delete database A) arrived the Cosmos DB server but the response never returned or a 408 Timeout returned, then the database name ("A") will still remain in the list of Cosmos DB Studio, but user cannot operate on that database anymore (because there is no database A in the Cosmos server anymore).
Bug Description
When using the Cosmos DB Studio, it is possible to encounter transient errors, and the application cannot handle such errors (like 503 Server Busy) now. When the transient error happens, the application would even have an inconsistent view with the real service. For instance, if a database deletion request (use the SDK API DeleteAsync to delete database A) arrived the Cosmos DB server but the response never returned or a 408 Timeout returned, then the database name ("A") will still remain in the list of Cosmos DB Studio, but user cannot operate on that database anymore (because there is no database A in the Cosmos server anymore).
Discussion
As this document shown, there are some transient error codes (408, 410, 429, 449 and 503) that we can retry on: https://docs.microsoft.com/en-us/azure/cosmos-db/sql/conceptual-resilient-sdk-applications#should-my-application-retry-on-errors
Additional Context
We are willing to discuss the transient error handlings and write a PR for this issue.