print cannot read items with numeric or hierarchical partition keys

Start in PrintCommand.cs: the PartitionKey property is typed as string and PrintItemAsync always builds new PartitionKey(this.PartitionKey). Read CreatePartitionKeyFromArgument, which rm, batch and stored procedures already use, to see how typed keys are parsed. Done when print reads the numeric 680 and string "680" documents with the same id separately, reads a mixed-type hierarchical key correctly, and keeps the not-found and input-error paths distinct. The end-to-end tests need an emulator or test account, and the typed-input syntax still has to be designed.

Summary

print binds its partition-key argument to string and always constructs the Cosmos SDK string partition key. Numeric and hierarchical partition keys are valid in Cosmos DB for NoSQL, but this command cannot address them correctly. Both failures were observed in the same provisioning verification run.

Observed with Cosmos DB Shell 1.1.271-preview during Azure provisioning verification. The same implementation remains in the current source revision linked below. Typed SDK point reads succeeded for the inserted documents.

Example 1: Numeric Partition Key

Given a Products container in database Demo configured with partition-key path /productId, insert:

{
  "id": "product-680",
  "docType": "product",
  "productId": 680,
  "name": "Road Frame"
}

Then run:

print product-680 680 --database=Demo --container=Products

Actual: the command sends partition key "680" as a JSON string, not numeric 680. It addresses the wrong logical partition and reports that the item is not found.

Expected: provide an unambiguous way to supply a numeric partition key and return this document. Merely removing command-line quotes does not help while the argument is bound to a C# string.

The equivalent typed SDK read works:

using var response = await container.ReadItemStreamAsync(
    "product-680", new PartitionKey(680d));

Example 2: Numeric-Looking String Must Remain Distinct

This is also a valid document in the same container:

{
  "id": "product-680",
  "docType": "product",
  "productId": "680",
  "name": "String-keyed product"
}

Numeric 680 and string "680" are different partition-key values. Both documents can use the same id because they occupy different logical partitions. With both present, the current implementation addresses the string-keyed document, even when the caller intends the numeric one.

A fix must preserve this distinction instead of guessing that every numeric-looking string should become a number. An explicit typed/JSON input mechanism is one option; its precise CLI syntax can be chosen as part of the fix.

Example 3: Mixed-Type Hierarchical Partition Key

Given a Customers container in database Demo with ordered hierarchical partition-key paths /customerId and /id, insert:

{
  "id": "customer-1001",
  "docType": "customer",
  "customerId": 1001,
  "name": "Example Customer"
}

The complete partition key is [1001, "customer-1001"]: a number followed by a string.

This attempted invocation on 1.1.271-preview failed:

print customer-1001 '[1001,"customer-1001"]' --database=Demo --container=Customers

Actual: the JSON-looking argument becomes one string-valued partition-key component, not two typed components. The observed read failed with HTTP 400. Changing outer quoting did not resolve it.

Expected: accept an explicitly typed, complete hierarchical key, preserve component order and types, and return the intended document. The command above records an attempted reproduction, not a requirement that this become the final supported syntax.

The equivalent typed SDK read succeeded:

var key = new PartitionKeyBuilder()
    .Add(1001d)
    .Add("customer-1001")
    .Build();
using var response = await container.ReadItemStreamAsync("customer-1001", key);

The migration ultimately verified all 36 synthetic documents with typed SDK point reads; this fallback should not be necessary solely because their partition keys are non-string or hierarchical.

Root Cause

PrintCommand.PartitionKey is declared as string?, and PrintItemAsync calls:

new PartitionKey(this.PartitionKey)

That always selects the SDK string overload. The positional-argument binder first converts evaluated arguments to text, and print does not parse that text into typed scalar or hierarchical components.

The shared CreatePartitionKeyFromArgument helper already provides typed parsing for other commands, including rm, batch, and stored procedures. It is a reuse candidate, but adopting automatic parsing must not silently reinterpret existing numeric-looking string keys. The fix should define an explicit typed-input contract and validate supported components and complete hierarchical keys.

Source: PrintCommand.

Cosmos DB explicitly supports numeric partition-key values: partition-key documentation.

Impact and Acceptance Criteria

• Valid numeric-key and hierarchical-key documents cannot be reliably point-read with print; migration verification had to use a separate typed SDK reader.
• Support numeric keys and complete, ordered hierarchical keys without changing stored documents, IDs, partition-key types, or container definitions.
• Preserve existing string-key behavior, including numeric-looking string values.
• Add regression coverage for numeric and string keys with the same item ID, proving each read returns the intended document.
• Keep genuine missing-item errors distinct from input/type errors.
• Document the supported typed-input and quoting syntax in command help and examples, including how to request a numeric-looking string explicitly.

End-to-End Regression Coverage

Exercise the actual Shell parser, argument binding, command dispatch, and SDK point read against an emulator or isolated Cosmos DB for NoSQL test account. Use synthetic fixtures and independently verify their stored key types through the SDK. Parser-only, disconnected-state, and command-help checks are not sufficient.

• Numeric versus string: create documents with the same item ID and partition keys 680 and "680", with different marker fields. Read each through the supported Shell syntax and assert the correct returned marker and JSON key type.
• Hierarchical keys: cover two- and three-component keys mixing strings, numbers, and booleans. Include same-ID documents whose tuples differ only by a numeric versus string component; assert exact document selection, component order, and types.
• Other scalar forms: cover ordinary strings, explicitly typed booleans, and explicit null keys, retaining their distinction from the strings "true" and "null".
• Invalid and missing inputs: cover malformed typed JSON, object or nested-array components, and incomplete/extra hierarchical components. Report actionable input errors; a well-formed key for a missing item must still produce the normal not-found result.
• Provisioning verification: seed a mixed-key fixture set, run print for every expected (id, full partition key) pair, and compare returned document content with the fixtures, ignoring only service-generated metadata. Do not count a query fallback as a successful point read or rewrite stored keys to make the test pass.

Retain focused unit tests for key conversion and backward compatibility in addition to this end-to-end coverage.

This issue is separate from throughput authentication and the VS Code MCP transport-detection failure.