GetFeedRanges was introduced during beta, so technically its signature is still changeable. Two improvements are proposed to align it with the new split-resilient change feed infrastructure from #26768.
- Add options parameter for force-refresh
Current signature:
func (c *ContainerClient) GetFeedRanges(ctx context.Context) ([]FeedRange, error)
Proposed signature:
func (c *ContainerClient) GetFeedRanges(ctx context.Context, o *FeedRangeOptions) ([]FeedRange, error)
GetFeedRanges now reads from the partitionKeyRangeCache (introduced in #26723). Today there is no way for a caller to force a cache refresh — the only refresh path is internal (410/Gone retry inside GetChangeFeed). A GetFeedRangesOptions struct with a ForceRefresh bool field would let callers explicitly invalidate stale routing data.
This also follows the Azure SDK Go convention of (ctx, *Options) signatures for all public methods.
- Slim down cached partitionKeyRange fields
The partitionKeyRange struct currently holds 12+ fields. The cached struct should be slimmed to retain only the fields the routing layer and downstream consumers actually consult:
Kept (6 fields):
- ID — range identity for routing
- MinInclusive — EPK lower bound
- MaxExclusive — EPK upper bound
- Status — range health/state
- ThroughputFraction — used by downstream consumers
- Parents — split lineage tracking
Dropped (8 fields):
- ResourceID (_rid)
- SelfLink (_self)
- ETag (_etag)
- LastModified (_ts)
- ResourceIDPrefix (ridPrefix)
- LSN
- OwnedArchivalPKRangeIds
- TargetThroughput (if present)
This reduces per-range memory overhead in the collectionRoutingMap cache without affecting the public FeedRange surface (MinInclusive + MaxExclusive only). Similar changes have been done in other SDKs as well, Rust for reference: Azure/azure-sdk-for-rust#4393
Breaking change: GetFeedRanges now reads from the cache. Any internal code path that accessed dropped fields (e.g., ResourceID, ETag) through the cached partitionKeyRange will need to be updated. External callers only see FeedRange so the public API is unaffected.
GetFeedRangeswas introduced during beta, so technically its signature is still changeable. Two improvements are proposed to align it with the new split-resilient change feed infrastructure from #26768.Current signature:
Proposed signature:
GetFeedRangesnow reads from the partitionKeyRangeCache (introduced in #26723). Today there is no way for a caller to force a cache refresh — the only refresh path is internal (410/Gone retry inside GetChangeFeed). A GetFeedRangesOptions struct with a ForceRefresh bool field would let callers explicitly invalidate stale routing data.This also follows the Azure SDK Go convention of (ctx, *Options) signatures for all public methods.
The partitionKeyRange struct currently holds 12+ fields. The cached struct should be slimmed to retain only the fields the routing layer and downstream consumers actually consult:
Kept (6 fields):
Dropped (8 fields):
This reduces per-range memory overhead in the collectionRoutingMap cache without affecting the public FeedRange surface (MinInclusive + MaxExclusive only). Similar changes have been done in other SDKs as well, Rust for reference: Azure/azure-sdk-for-rust#4393
Breaking change: GetFeedRanges now reads from the cache. Any internal code path that accessed dropped fields (e.g., ResourceID, ETag) through the cached partitionKeyRange will need to be updated. External callers only see FeedRange so the public API is unaffected.