Summary
read-strategy.mdx documents the AZ Affinity All Nodes strategy with a Python example, and every other language tab is a "Coming soon" placeholder. Two of those are now wrong:
Where
src/content/docs/how-to/connections/read-strategy.mdx, in the ### AZ Affinity All Nodes section:
The prose, the summary table at line 20, and the routing table in concepts/client-features/command-routing.mdx:31 are all accurate and need no change. This is only about the per-language tabs.
What's needed
Replace the Go and Java placeholders with examples following the pattern already used by the AZ Affinity Replicas and Primary tabs in the same file (Java at lines 336-355, Go at 389-400) — builder, readFrom, the AZ setting, then set/get with a comment on where the read lands.
Java, for reference:
import glide.api.GlideClusterClient;
import glide.api.models.configuration.GlideClusterClientConfiguration;
import glide.api.models.configuration.NodeAddress;
import glide.api.models.configuration.ReadFrom;
GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder()
.address(NodeAddress.builder()
.host("address.example.com")
.port(6379)
.build())
.readFrom(ReadFrom.AZ_AFFINITY_ALL_NODES)
.clientAZ("us-east-1a")
.build();
GlideClusterClient client = GlideClusterClient.createClient(config).get();
client.set("key1", "val1").get();
// get will read from any node (primary or replica) in the same client's availability zone,
// in round robin, if any exist
client.get("key1").get();Go uses config.AzAffinityAllNodes.
Worth noting for the Java tab: clientAZ is required, and unlike the other bindings the Java client rejects a missing or blank value with a ConfigurationError from createClient rather than silently falling back.
Notes
No per-binding support matrix tracks this (feature-comparison.md has no read-strategy rows), so these tab placeholders are the only signal to users — which is why the stale Go one matters.
Since the tabs are per-language, this can be closed in one PR or split per binding. The remaining placeholders (Node, C#, PHP, Ruby) should be cleared as valkey-io/valkey-glide#6791, valkey-io/valkey-glide-csharp#533, valkey-io/valkey-glide-php#316, and valkey-io/valkey-glide-ruby#294 land.
Summary
read-strategy.mdxdocuments theAZ Affinity All Nodesstrategy with a Python example, and every other language tab is a "Coming soon" placeholder. Two of those are now wrong:AZ_AFFINITY_ALL_NODESread strategy valkey-glide#7059.Where
src/content/docs/how-to/connections/read-strategy.mdx, in the### AZ Affinity All Nodessection:The prose, the summary table at line 20, and the routing table in
concepts/client-features/command-routing.mdx:31are all accurate and need no change. This is only about the per-language tabs.What's needed
Replace the Go and Java placeholders with examples following the pattern already used by the
AZ Affinity Replicas and Primarytabs in the same file (Java at lines 336-355, Go at 389-400) — builder,readFrom, the AZ setting, thenset/getwith a comment on where the read lands.Java, for reference:
Go uses
config.AzAffinityAllNodes.Worth noting for the Java tab:
clientAZis required, and unlike the other bindings the Java client rejects a missing or blank value with aConfigurationErrorfromcreateClientrather than silently falling back.Notes
No per-binding support matrix tracks this (
feature-comparison.mdhas no read-strategy rows), so these tab placeholders are the only signal to users — which is why the stale Go one matters.Since the tabs are per-language, this can be closed in one PR or split per binding. The remaining placeholders (Node, C#, PHP, Ruby) should be cleared as valkey-io/valkey-glide#6791, valkey-io/valkey-glide-csharp#533, valkey-io/valkey-glide-php#316, and valkey-io/valkey-glide-ruby#294 land.