Valid vector, ranking, and DISTINCT queries fail when reading unsupported continuation tokens

The bug is in QueryCommand.ExecuteQueryAsync at line 753, where it unconditionally reads response.ContinuationToken. Start by examining the CosmosQueryResponseMessageHeaders.ContinuationToken getter and the DisallowContinuationTokenMessages class. Write a test in CommandTests/QueryCommandTests.cs that reproduces the error with a vector ORDER BY query. The fix must handle non-resumable pipelines without truncating results.

Summary

The query command fails on valid vector, relevance-ranking, and object-shaped DISTINCT queries because it unconditionally reads ResponseMessage.ContinuationToken. The Cosmos .NET SDK throws from that property when a query pipeline does not support exporting continuation tokens, even when query execution succeeded and no continuation token was supplied.

Query execution and the ability to export a resumable continuation token must be handled separately.

Reported reproduction

The investigation used two containers with eight synthetic documents each:

• One without a vector index.
• One with a flat vector index and a three-dimensional float32/cosine embedding policy.

Documents include id, embedding, text, and category properties. Each failing invocation used max: 10, format: "json", and no input continuation token. The shell remained connected; this was a command failure, not a process crash.

The same queries reportedly succeeded through the JavaScript SDK against the same containers. Expected IDs below describe that fixture, not universal results.

1. Vector ORDER BY

SELECT TOP 3 c.id
FROM c
ORDER BY VectorDistance(c.embedding, [1,0,0], false,
    {distanceFunction: "Cosine", dataType: "Float32"})

Reported on both containers. Also reported with true instead of false on the unindexed container, and with the following query on the indexed container:

SELECT TOP 3 c.id
FROM c
ORDER BY VectorDistance(c.embedding, [1,0,0])

Actual: Continuation tokens are not supported for the non streaming order by pipeline.

Expected: Return the query results; the JavaScript SDK returned IDs 1, 2, 6.

2. Relevance-ranking queries

Each of these queries was reported to fail on the unindexed container:

SELECT TOP 3 c.id FROM c
ORDER BY RANK VectorDistance(c.embedding, [1,0,0], true,
    {distanceFunction: "Cosine", dataType: "Float32"})

SELECT TOP 3 c.id FROM c
ORDER BY RANK FullTextScore(c.text, "cosmos")

SELECT TOP 3 c.id FROM c
ORDER BY RANK RRF(
    VectorDistance(c.embedding, [1,0,0], true, {distanceFunction: "Cosine"}),
    VectorDistance(c.embedding, [1,0,0], true, {distanceFunction: "Cosine"}))

Also reported on the indexed container with:

SELECT TOP 3 c.id FROM c
ORDER BY RANK VectorDistance(c.embedding, [1,0,0])

Actual: Continuation tokens are not supported by hybrid search.

Expected: Return the query results; the JavaScript SDK returned IDs 1, 2, 6 for vector/RRF and 2, 1, 5 for full-text. The full-text observation is specific to the reported fixture and is not a general guarantee about index requirements.

3. Object-shaped DISTINCT with ORDER BY

SELECT DISTINCT c.category FROM c ORDER BY c.category

Actual: DISTINCT queries only return continuation tokens when there is a matching ORDER BY clause. The error recommends adding ORDER BY even though the query already has it.

Expected:

[{"category":"A"},{"category":"B"},{"category":"C"}]

The scalar projection is a working control:

SELECT DISTINCT VALUE c.category FROM c ORDER BY c.category

It returns ["A","B","C"]. Ordinary ORDER BY pagination also successfully returned and consumed a continuation token.

Source evidence

Inspected shell revision: 8db03d07d47ca8e5aa1ae7c5f2a400536d18912d.

The repository references Microsoft.Azure.Cosmos 3.59.0-preview.0. The installed package's source revision is 9e6a2f6d06639c62243863f8c152c324c84a0069; SDK links below are pinned to that revision.

1. QueryCommand.ExecuteQueryAsync creates the stream iterator, reads a response, checks its success status, and parses its content. At line 753, before collecting the returned documents, it unconditionally assigns returnState.ContinuationToken = response.ContinuationToken.
2. SDK ResponseMessage.ContinuationToken delegates to the response headers.
3. CosmosQueryResponseMessageHeaders.ContinuationToken throws ArgumentException when DisallowContinuationTokenMessage is non-null. This does not require an input continuation token.
4. All three reported error strings exactly match the SDK's DisallowContinuationTokenMessages.
5. SDK QueryIterator can construct a successful response containing documents and a disallowed-continuation message. It keeps the iterator available to advance until the pipeline completes.
6. The hybrid-search pipeline returns pages marked with this restriction. The DISTINCT pipeline does the same for unordered DISTINCT.

The getter failure mechanism is confirmed by source inspection. The reported live results were not independently rerun during this review. The exact query-plan classification behind the object-shaped DISTINCT case remains to be verified; the generic continuation error alone does not establish that its SQL is invalid.

Correctness constraints for the fix

Do not simply catch the getter exception and treat a missing token as completion.

Official query pagination documentation explains that:

• MaxItemCount is an upper bound per query execution, not a guarantee about page size.
• Responses can contain fewer items than requested, including zero items.
• All pages must be processed to obtain accurate results.
• Continuation support has query-shape limitations; its DISTINCT example uses SELECT DISTINCT VALUE ... ORDER BY ....

Consequently, TOP 3 with max: 10 does not guarantee a single response. Non-resumable pipelines may still require advancing the same iterator, including through empty intermediate pages. Unsupported token export must not become silent truncation or false exhaustion.

Acceptance criteria

• Valid queries do not fail solely because their successful response cannot expose a continuation token.
• Non-resumable queries advance the same iterator as needed, including through empty intermediate pages, while respecting the command's result limit.
• If a bounded result is incomplete and cannot be resumed, that condition is explicit; do not report it as an exhausted result set.
• Existing resumable pagination remains functional.
• Cancellation, genuine query errors, output formatting, and request-charge accounting remain correct.
• Add response-level regression tests for each reported restriction, including successful responses whose continuation getter throws, multi-page/empty-page execution, and results exceeding the configured limit.
• Retain a normal resumable-query control and the ordered scalar-DISTINCT control.
• Update query documentation if result-limit or completion reporting changes.

Existing query tests cover document collection, limits, formatting, and metrics, but the review found no regression test for this successful-response/throwing-continuation-getter case.