Serverless database/container creation fails because omitted throughput options default to autoscale 1000 RU/s

[sevoku]

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

• mkcon and create container / create c
• mkdb and create 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

• ThroughputErrorsTests checks recognition of serverless error messages, not creation behavior.
• MakeContainerCommandTests checks partition keys and unique keys, not throughput omission.
• MakeDbCommandTests asserts 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:

• Bug: settings command fails on serverless account (offers API 400) #138: settings fails when reading offers on serverless.
• Bug: Scale settings fails on serverless accounts with offer API 400 #136 and Bug: Scale settings fails on serverless accounts with offer API 400 #137: Scale settings issue reports for unsupported offers operations.
• Settings should handle expected errors gracefully #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.