rls: implement stale_header_data caching and propagation in RLS - #12972
Open
AgraVator wants to merge 2 commits into
Open
rls: implement stale_header_data caching and propagation in RLS#12972AgraVator wants to merge 2 commits into
AgraVator wants to merge 2 commits into
Conversation
This PR implements stale_header_data caching and propagation for Route Lookup Service (RLS) in :grpc-rls, addressing Buganizer issue b/542322498 ([CS][DirectPath] gRPC Java does not handle RLS stale_header_data properly). Background & Context: When using Cloud Spanner Route Lookup Service (RLS), the RLS control plane returns a header_data fingerprint token in RouteLookupResponse. The client is expected to cache this token and reuse it in: 1. Subsequent background control-channel refresh requests (RouteLookupRequest with reason = REASON_STALE and stale_header_data = <cached_token>). 2. Attached metadata headers (X-Google-RLS-Data) on picked data RPC requests. This implementation aligns gRPC Java with the Go gRPC client RLS implementation (balancer/rls/picker.go and balancer/rls/control_channel.go). Key Changes: - RlsProtoData.java: Added @nullable String staleHeaderData() property to RouteLookupRequest. - RlsProtoConverters.java: Updated RouteLookupRequestConverter to serialize/deserialize stale_header_data. - CachingRlsLbClient.java: Updated asyncRlsCall and DataCacheEntry.maybeRefresh() to pass getHeaderData() on REASON_STALE. - Unit & Stress Test Coverage: Added tests in RlsProtoConvertersTest, CachingRlsLbClientTest, and StaleHeaderDataStressTest. Testing & Verification: - Executed ./gradlew :grpc-rls:test --rerun-tasks - Result: All 82 unit and stress tests in :grpc-rls passed cleanly. Fixes b/542322498
AgraVator
marked this pull request as ready for review
August 5, 2026 16:22
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements stale_header_data caching and propagation for Route Lookup Service (RLS) in :grpc-rls, addressing gRPC Java does not handle RLS stale_header_data properly).
Background & Context:
The RLS control plane returns a header_data fingerprint token in RouteLookupResponse. The client is expected to cache this token and reuse it in:
This implementation aligns gRPC Java with the Go gRPC client RLS implementation (balancer/rls/picker.go and balancer/rls/control_channel.go).
Fixes b/542322498