Self-review: PR #938 (RangeScan retry)

Code correctness

Retry logic — Same backoff.RetryNotify + FindLeaderHint pattern as List PR and read/write batches. retryCtx (with requestTimeout) is correctly used for both backoff timing and RPC calls.

Duplicate prevention — Same dataSent flag approach as List PR. Retries only before data flows to the channel.

Behavior change: close(ch) is now always called

The original rangeScanFromShard had a subtle issue:

client, err := c.executor.ExecuteRangeScan(ctx, request, nil)
if err != nil {
    ch <- GetResult{Err: err}
    return  // ← channel NOT closed
}
defer close(ch)  // ← only set up on success

If ExecuteRangeScan failed (e.g. connection refused), the channel was never closed. In the single-shard path, the consumer would receive the error but never see channel close — any for range ch would block forever after the error.

The new code always calls close(ch) at the end of rangeScanFromShard:

if err != nil {
    ch <- GetResult{Err: err}
}
close(ch)

This is a bug fix — the consumer now always sees a proper channel close. In the multi-shard path, the per-shard channels are also always closed, which lets aggregateAndSortRangeScanAcrossShards know the shard is done.

Observations

1. requestTimeout may be tight for large RangeScan operations — same observation as List PR. Consistent with other retry paths.

2. Test pre-allocates results slice (make([]oxia.GetResult, 0, 2)) to satisfy prealloc lint.

3. Both PRs export IsRetriable independently — merge-order safe.

Verdict

LGTM. The close(ch) change is an improvement over the original behavior.