[sushanb]

Problem

ClientConfigurationManager constructs a single io.grpc.Metadata instance in its constructor and passes that same mutable reference to ClientCall.start(listener, metadata) on every GetClientConfiguration poll and retry. In grpc-java, ClientCall.start() takes ownership of the Metadata instance, and channel ClientInterceptors wrap realChannel above RetriableStream and mutate headers in place before any defensive copy is made. Whenever a channel ClientInterceptor (for example MetadataUtils.newAttachHeadersInterceptor or a tracing interceptor calling headers.put(...) in start()) appends per-RPC headers without discardAll, duplicate header entries accumulate on ClientConfigurationManager.metadata every 5 minutes until outbound header encoding exceeds the server's HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE (64 KiB), causing Netty's HpackEncoder to fail every subsequent poll locally with Status.INTERNAL: http2 exception (HeaderListSizeException) — surviving replaceChannel() until JVM restart.

Fix

• Copy this.metadata into a fresh Metadata instance per ClientCall in ClientConfigurationManager.sendRequest(), matching gax-grpc's GrpcClientCalls, BigtableChannelPrimer, and SessionPoolImpl.

Testing

• Added metadataDoesNotAccumulateAcrossPollsWithHeaderAttachingInterceptor verifying 26 consecutive polls against a server advertising maxInboundMetadataSize(1024) with a header-appending ClientInterceptor succeed without header accumulation (1 copy of each header per poll on the wire).

[gemini-code-assist]

Code Review

This pull request improves the ClientConfigurationManager by preventing metadata accumulation across polls, avoiding retry amplification during background polls when falling back to the default configuration, and introducing a mockable Clock for better testability. It also adds comprehensive unit tests to verify these behaviors. The reviewer's feedback highlights an issue in the logging implementation where concatenating a Throwable into a log message discards the stack trace and suggests a Java 8-compatible logging pattern to preserve the stack trace and avoid unnecessary string concatenation.

[gemini-code-assist]

Concatenating the throwable into the log message string only prints its toString() representation, which discards the stack trace. For Level.FINE logs, having the full stack trace of the failed RPC is extremely valuable for debugging network or gRPC issues. Additionally, the lambda-based logging overload log(Level, Throwable, Supplier) is only available in Java 9+. If this library targets Java 8 compatibility, using standard log(Level, String, Throwable) wrapped in logger.isLoggable(Level.FINE) is safer and avoids string concatenation overhead when FINE logging is disabled.

Suggested change

	if (willRetry) {
	logger.log(
	Level.FINE,
	() ->
	"Failed to fetch client config (attempt "
	+ (attempt + 1)
	+ "), retrying: "
	+ throwable);
	} else if (!isInitialPoll && !shouldReset) {
	if (willRetry) {
	if (logger.isLoggable(Level.FINE)) {
	logger.log(
	Level.FINE,
	"Failed to fetch client config (attempt " + (attempt + 1) + "), retrying",
	throwable);
	}
	} else if (!isInitialPoll && !shouldReset) {