Problem
LazyQueryPlan is intended to be lazy in the sense that routing should select the first node for the request, then only generate additional nodes if the SDK retries and asks for another target.
Today the implementation is only lazy until first access. ensureInitialized() snapshots and builds the full remaining plan when hasNext() or next() is first called. In seeded/key-affinity mode this can call drainSeeded(...), which computes the entire deterministic order up front even though most requests only use the first node.
Why this matters
For the common successful request path, the client should avoid doing work needed only for retries. This is especially relevant for key-affinity plans, where we only need the first active node initially; the rest of the deterministic sequence is only needed after a failure/retry.
Desired behavior
- Create the request plan in
beforeExecution as today.
- On first routing attempt, compute only the first target node.
- If that attempt fails and the SDK retries, compute the next target then.
- Keep existing no-duplicate behavior across retries.
- Keep seeded/key-affinity ordering compatible with the existing Go-compatible
GoRand pick-and-remove sequence.
- Preserve the current key-affinity behavior where the deterministic ring is based on all discovered scoped nodes and inactive nodes are skipped.
Notes
This likely means LazyQueryPlan should keep a mutable candidate set and a PRNG/cursor, but not materialize the full ordered retry list in ensureInitialized(). hasNext() may need at most a one-node lookahead because the AWS SDK calls it before next(), but it should not drain the full plan.
Problem
LazyQueryPlanis intended to be lazy in the sense that routing should select the first node for the request, then only generate additional nodes if the SDK retries and asks for another target.Today the implementation is only lazy until first access.
ensureInitialized()snapshots and builds the full remaining plan whenhasNext()ornext()is first called. In seeded/key-affinity mode this can calldrainSeeded(...), which computes the entire deterministic order up front even though most requests only use the first node.Why this matters
For the common successful request path, the client should avoid doing work needed only for retries. This is especially relevant for key-affinity plans, where we only need the first active node initially; the rest of the deterministic sequence is only needed after a failure/retry.
Desired behavior
beforeExecutionas today.GoRandpick-and-remove sequence.Notes
This likely means
LazyQueryPlanshould keep a mutable candidate set and a PRNG/cursor, but not materialize the full ordered retry list inensureInitialized().hasNext()may need at most a one-node lookahead because the AWS SDK calls it beforenext(), but it should not drain the full plan.