Serverless database/container creation fails because omitted throughput options default to autoscale 1000 RU/s
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 55/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C#
- Stelle
- 3
- Fork
- 7
- Merge medio
- 1g 7h
- PR unite (30g)
- 19
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Azure/CosmosDBShell
-
Valid vector, ranking, and DISTINCT queries fail when reading unsupported continuation tokens Apertabug P1
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
Azure/CosmosDBShell#219 ·
-
automation P1
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
Azure/CosmosDBShell#178 · 1 commento ·
-
automation P1
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
Azure/CosmosDBShell#175 · 1 commento ·
-
agentic enhancement P1
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
Azure/CosmosDBShell#159 · 2 commenti ·
-
agentic enhancement P0
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
Azure/CosmosDBShell#153 · 1 commento ·
Tutte le issue di Azure/CosmosDBShell
Issue simili
-
core dependencies
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 80/100
-
bug frontend good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Down / Waiting for removal
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100