Azure / Azure/azure-cosmos-client-engine

Add `drain` field to `QueryRequest`

Open
#25 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
2
Forks
10
PR merge metrics
No merged PRs in 30d

Description

A `QueryRequest` is sent from the pipeline over to the SDK in order to execute a request to fetch more data. For unordered and streaming queries, we want to process one page of results at a time (or sometimes one page from each partition) so we can yield results quickly and avoid extra calls if the user stops enumerating results. However, for non-streaming queries, we have to collect all the data from all partitions before we can even yield a single item. This results in a number of "chatty" iterations between the SDK and the driver as the SDK gets a set of requests for each partition, fetches incomplete data (because there are multiple pages of results to fetch) and then the pipeline yields no items and only more requests. In this scenario, the pipeline _knows_ that it needs the SDK to "drain" every partition (fetch data until responses no longer contain continuations). We should give the pipeline a field it can set in a `QueryRequest` that signals to the SDK that it should collect all the results for a given partition (and in the case of cross-partition queries, we'd return one of these for each partition) before bothering to ask for any items. That would reduce the number of API calls going between the SDK and the pipeline.

Contributor guide

Open the contributing guide

Research direction

Start by locating the Rust definition of QueryRequest and tracing how the pipeline sends partition requests to the SDK. Verify how continuations and non-streaming results are handled; done means a request can signal draining so each partition is fetched until its responses no longer contain continuations before items are requested.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, distributed-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.