Azure / Azure/azure-sdk-for-rust

PKRange resolution API follow-ups from PR #4342

Open
#4,380 0 comments 0 reactions 1 assignee Claimed by @analogrelay View on GitHub
Cosmos
Dominant language
Rust
Stars
884
Forks
365
Avg merge
2d 19h
Merged PRs (30d)
109

Description

Follow-up work items from the review of #4342 (Route PKRange resolution through driver).

### 1. Prevent empty routing maps in the driver PKRange cache

The driver's `PartitionKeyRangeCache` can fall back to an empty `ContainerRoutingMap` on service or parse failures. A valid container always has at least one partition key range, so an empty result should be treated as a resolution failure — not silently cached. The SDK currently works around this with retry-then-error logic in `read_feed_ranges()` and `feed_range_from_partition_key()`, but the root fix belongs in the driver.

**Files:**
- `sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs` (`resolve_all_partition_key_ranges`, `resolve_partition_key_ranges_for_key`)
- `sdk/cosmos/azure_data_cosmos/src/clients/container_client.rs` (empty-cache workarounds in `read_feed_ranges` and `feed_range_from_partition_key`)

### 2. Replace `feed_range_from_partition_key` with `FeedRange::for_partition_key`

`ContainerClient::feed_range_from_partition_key()` currently resolves the physical partition that *currently* contains a given partition key, which is incorrect — physical partition assignments change during splits/merges. The PK-to-FeedRange mapping should be purely hash-based with no I/O. Replace this with a `FeedRange::for_partition_key()` constructor that computes the EPK hash directly, aligning with the Python and Java SDKs.

**File:** `sdk/cosmos/azure_data_cosmos/src/clients/container_client.rs`

### 3. Use `FeedRange` terminology in driver PKRange resolution APIs

The driver's public `resolve_all_partition_key_ranges()` and `resolve_partition_key_ranges_for_key()` expose raw `PartitionKeyRange` objects. As `FeedRange` moves to the driver for feed operations, these APIs should return `FeedRange`s instead. The driver should be the only component that sees physical partition metadata (PK Range ID); everything above it should work with `FeedRange`s.

**File:** `sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs`

### 4. Add unit tests for driver PKRange resolution methods

`resolve_all_partition_key_ranges()` and `resolve_partition_key_ranges_for_key()` have non-trivial logic (full vs. prefix key behavior, `force_refresh` interaction, empty-cache fallback) but no unit tests. Add tests covering:
- Full keys — single range returned via point lookup
- MultiHash prefix keys — multiple overlapping ranges returned
- Failure / empty-routing-map scenarios — verify `None` is returned, not `Some(vec![])`

**File:** `sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs`

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.