Serverless database/container creation fails because omitted throughput options default to autoscale 1000 RU/s
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
Research direction
The issue is in CosmosArmResourceProvider.cs and DataPlaneCosmosResourceOperations.cs where throughput defaults are set. Start by examining the CreateUpdateConfig and CreateThroughputProperties methods. Look for where serverless account detection can be added to omit throughput. Run the existing tests in MakeContainerCommandTests and MakeDbCommandTests to understand the current behavior, then write a test for serverless creation.
Written by the indexing model from the issue text.
Description
Summary
Creating a container on a serverless Azure Cosmos DB for NoSQL account fails because CosmosDBShell supplies provisioned throughput even when the user omits --scale and --ru.
Both the Azure Resource Manager (ARM) and data-plane creation paths default to autoscale with a maximum of 1,000 RU/s. Serverless accounts must not receive provisioned-throughput settings. Database creation uses the same defaulting logic and is affected as well.
A user reported this while creating a container on a real serverless account. Local source inspection confirms the request-construction defect. This investigation did not reproduce the operation against the live account, and the exact original service error and installed shell version were not captured. The account hostname is intentionally omitted.
Affected commands
mkconandcreate container/create cmkdbandcreate database/create db- CLI and MCP invocations that use these command implementations
- Both ARM-backed creation (normally Entra ID connections) and data-plane-backed creation (keys, emulator, static-token connections)
Reproduction steps
Prerequisite: connect to a serverless Azure Cosmos DB for NoSQL account using an identity authorized to create the relevant resource. For Entra ID resource management, ensure ARM context and the appropriate management-plane permissions are available.
For container creation, use an existing database so database creation does not mask the problem:
cd /ExistingDatabase
mkcon ServerlessRepro /pk
Equivalent entry points include:
create container ServerlessRepro /pk
mkcon ServerlessRepro /pk --database ExistingDatabase
For database creation, navigate to the account root:
cd /
mkdb ServerlessReproDb
Or use create database ServerlessReproDb.
These examples are reproduction instructions derived from the code, not a transcript of a new live-account test.
Expected behavior
With no throughput options, database and container creation should work on a serverless account without sending manual or autoscale throughput settings.
If a user explicitly supplies incompatible throughput options for a serverless account, the shell should explain the incompatibility clearly rather than silently ignoring those options or exposing an avoidable low-level service error.
Actual behavior and root cause
Source revision inspected: 8db03d07d47ca8e5aa1ae7c5f2a400536d18912d.
ARM path
CosmosArmResourceProvider.CreateUpdateConfig computes maxRu ?? 1000. Unless scale is manual or m, it returns AutoscaleMaxThroughput = ru.
Both CreateDatabaseAsync and CreateContainerAsync put this result into the create request's Options, without checking serverless capability.
Data-plane path
DataPlaneCosmosResourceOperations.CreateThroughputProperties similarly defaults to ThroughputProperties.CreateAutoscaleThroughput(1000).
The result is passed to CreateDatabaseIfNotExistsAsync and CreateContainerIfNotExistsAsync, rather than omitting throughput.
No supported omission workaround
Omitting both options still produces autoscale throughput. --scale=none or --scale=serverless is not a workaround: values other than manual/m currently fall through to autoscale. Setting RU/s to zero would still specify throughput rather than omit it.
The MakeDbCommand.CreateThroughputProperties helper also duplicates the defaulting behavior; its existing tests do not verify the backend request construction.
Existing coverage and validation
ThroughputErrorsTestschecks recognition of serverless error messages, not creation behavior.MakeContainerCommandTestschecks partition keys and unique keys, not throughput omission.MakeDbCommandTestsasserts the existing default and contains no serverless creation case.- Integration CI runs offline and emulator suites, not a live serverless-account suite.
Local validation on macOS using .NET SDK 10.0.401: app and test project builds succeeded; all 46 tests selected from MakeContainerCommandTests, MakeDbCommandTests, CreateCommandTests, ThroughputErrorsTests, and CosmosArmResourceProviderTests passed. This demonstrates the coverage gap, not successful serverless creation.
Proposed direction and acceptance criteria
- Make the creation-throughput decision account-aware, omitting throughput on serverless accounts when no throughput options were supplied.
- Support both ARM and data-plane connections; do not require ARM-only permissions for key-based connections merely to decide throughput behavior.
- Give an actionable error for explicitly supplied throughput options on serverless accounts; do not silently discard user intent.
- Preserve existing provisioned-account behavior unless a separate, intentional behavior change is agreed. Include shared-throughput databases in regression coverage.
- Verify actual ARM request payloads omit both manual and autoscale throughput fields on serverless, and actual data-plane SDK calls receive no throughput.
- Cover database and container creation, command aliases, omitted options, explicit manual/autoscale options, and provisioned-account regressions. Preserve partition-key, unique-key, and indexing-policy behavior.
- Do not swallow authentication, authorization, cancellation, or unrelated service failures during capability detection.
- Add an opt-in live serverless smoke test with explicit account configuration, isolated resource names, and cleanup; emulator-only testing cannot establish serverless compatibility.
- Update help/localization, README, and relevant command/MCP documentation with the supported behavior.
Related issues and documentation
Searches across open and closed issues for serverless, throughput, mkcon, and "create container" did not find an issue for this creation defect.
Related but distinct closed reports:
- #138:
settingsfails when reading offers on serverless. - #136 and #137: Scale settings issue reports for unsupported offers operations.
- #29: Graceful handling of expected settings/throughput errors.
Those reports concern inspecting or modifying settings on existing resources, rather than specifying throughput while creating resources.
Official reference: Azure Cosmos DB serverless.
- Dominant language
- C#
- Stars
- 3
- Forks
- 7
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 19
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/CosmosDBShell
-
bug P1
Difficulty 3/5 1-2 days Newbie friendliness 45/100
Azure/CosmosDBShell#219 ·
-
automation P1
Difficulty 5/5 Over a week Newbie friendliness 45/100
Azure/CosmosDBShell#178 · 1 comment ·
-
automation P1
Difficulty 5/5 Over a week Newbie friendliness 35/100
Azure/CosmosDBShell#175 · 1 comment ·
-
agentic enhancement P1
Difficulty 5/5 Over a week Newbie friendliness 35/100
Azure/CosmosDBShell#159 · 2 comments ·
-
agentic enhancement P0
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Azure/CosmosDBShell#153 · 1 comment ·
All issues in Azure/CosmosDBShell
Similar issues
-
bug frontend good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
apache/arrow-adbc#4809 ·