vscode-cosmosdb
vscode-cosmosdb copied to clipboard
Fail to create a collection to the attached Core(SQL) server which created using the "Serverless" capacity model
OS: Win10 Build Version: 20210923.1 Regression: Not a regression
Repro Steps:
- Create a Core(SQL) server with "Serverless" capacity model -> Right click the Core(SQL) server -> Select "Copy Connection String".
- Click "Attach Database Axccount..." icon -> Paste the copied connection string.
- Create a collection to the attached Core(SQL) server.
- Check whether succeed to create a collection to the attached Core(SQL) server.
Expect: Succeed to create a collection to the attached Core(SQL) server.
Actual:
Fail to create a collection to the attached Core(SQL) server.
More Info: Create a collection to the Core(SQL) server -> Expand the attached Core(SQL) server -> There is a collection and can create a document for it successfully.
Attached Accounts scenario for Azure is not a typical scenario as the database account is already available under the subscription tree. I don't see a value is fixing this issue as a priority. Is there a use case I might be missing?
This issue does't reproduce for the attached Mongo DB server which created using the "Serverless" capacity model or the attached Core(SQL) server which created using the "Provisioned Throughput" capacity model. It would be better to keep the attached Core(SQL) server consistent with other servers. From the user's point of view, creating a collection is a basic function, so it would be better if the collection can be created successfully.
Verified on the latest build 20211026.1, the error also reproduces for the attached Gremlin account which created using the "Serverless" capacity model.
This error is occurring because when create a collection with an attached serverless SQL(Core) account, we don't stifle the prompt for throughput like we do with the remote experience.
Entering a value in throughput is what is causing the error to occur. The workaround is to just type some bogus value in the prompt (it's not being validated, probably another bug we could file 😅)