rahul2393

feat(spanner): penalize channels that returned Unavailable or ResourceExhausted in the dynamic channel pool picker (#20390) Fixes: b/546194028

fix(spanner): record streaming built-in metrics per result stream (#20596) RowIterator recorded a built-in metrics operation on each call to Next that opened a stream. Operation latency was therefore about the time to the first result, a resumed stream was recorded as a second operation, and a non-retryable error after the first rows was never recorded as an operation. It also created a metrics tracer on every call to Next. Record one operation per result stream instead, matching the published definitions of the client-side metrics: https://cloud.google.com/spanner/docs/client-side-metrics-descriptions - The operation starts when the first stream is opened and ends when Next returns iterator.Done (OK) or an error (its status), or when Stop is called before that (OK). Its latency includes retries, backoff and the application time between calls to Next. Iterators that are neither read to the end nor stopped record nothing. - Every stream that is opened or resumed is an attempt of that operation, from its open until the stream ends or fails. The attempt count is still recorded when the operation ends. - The tracer is created when the first stream is opened and only when built-in metrics are enabled, so Next does no per-row metrics work. - The stream metrics interceptor sets the method before creating the stream, so a stream that fails to open is recorded as an attempt of its method. Attempts that fail before the RPC is sent are not recorded.

feat(spanner): support caller-owned OpenTelemetry client metrics (#20388) Internal Reference: go/built-in-metric-custom-export Java PR: https://github.com/googleapis/google-cloud-java/pull/13741

perf(spanner): skip reading response headers when no latency sink is enabled (#20583) Response headers carry the GFE/AFE server-timing latency. That latency feeds OpenCensus or OpenTelemetry GFE latency metrics, built-in metrics, and the `gfe.latency_ms` / `afe.latency_ms` attributes of recording spans. Several call paths copied and parsed these headers even when none of their consumers was enabled. This PR applies one rule to streaming, unary and BatchWrite calls: skip the header capture when nothing on that path uses it. This does **not** reduce network wait. The first `Recv()` on a stream always waits for the response headers, because they are sent before any data. What it removes is CPU and allocations: header map copies and server-timing parsing on the no-sink path.

fix(spanner): roll back read-write transaction before retrying caller-returned Aborted errors (#20131) Fixes: b/519914289 Returning a fabricated `codes.Aborted` error from a `ReadWriteTransaction` body (one the server never sent) makes the client retry the function without rolling back the current attempt. The server-side transaction stays alive holding its locks, so the retry immediately queues behind the previous attempt's own locks and stalls until the session or transaction times out. The fix tracks on the transaction whether an abort was actually observed from the server. When the retry loop sees an Aborted error that did not come from the server, it rolls the transaction back before starting the next attempt. Genuine server aborts behave exactly as before, including passing the previous transaction id on the retry so wound-wait priority is preserved. If that rollback itself fails, the error is surfaced as a non-retryable `FailedPrecondition` rather than retrying against a transaction in an unknown state. Concurrent readers waiting on an inline-streaming begin are also woken when the transaction aborts instead of blocking. Tests: mocked-server tests assert a `RollbackRequest` is sent between attempts for the fabricated-abort case and that none is sent for genuine server aborts, plus regression tests for explicit-begin transactions and a concurrent streaming-abort race. `go test ./...` in `spanner/` is green, including with `-race`.

perf(spanner): skip builtin metrics tracer allocation when metrics are disabled (#20582) Unary RPC wrappers allocated a builtin metrics tracer, operation state and read the clock on every call even when built-in metrics were disabled. The tracer factory now returns nil in that case and the wrappers, record functions and unary metrics interceptor handle a nil tracer. Server timing span attributes are still recorded for traced unary calls when metrics are disabled. Behavior with metrics enabled is unchanged. ## Benchmark Built-in metrics disabled (`DisableNativeMetrics: true`, no `ClientMetricsProvider`), in-memory Spanner server. Each op is a read-write transaction with one DML statement, which issues two unary RPCs (`ExecuteSql` with inline begin, then `Commit`). The benchmark is not included in this change. ``` goos: darwin goarch: arm64 cpu: Apple M2 Max go: go1.26.7 │ main │ this PR │ │ sec/op │ sec/op vs base │ DMLTransactionMetricsDisabled-12 165.1µ ± 5% 163.1µ ± 6% ~ (p=0.289 n=20) │ main │ this PR │ │ B/op │ B/op vs base │ DMLTransactionMetricsDisabled-12 51.05Ki ± 0% 49.17Ki ± 0% -3.69% (p=0.000 n=20) │ main │ this PR │ │ allocs/op │ allocs/op vs base │ DMLTransactionMetricsDisabled-12 745.0 ± 0% 721.0 ± 0% -3.22% (p=0.000 n=20) ``` ### Summary - With built-in metrics disabled, each unary RPC no longer allocates a metrics tracer, its operation state, the context value that carries it, or the server-timing parse result. That saves about **12 allocations and about 960 B per unary RPC** (24 allocations and about 1.9 KiB per transaction above). - The reduction is the same in every run (±0%), so it applies to every unary call. - Latency is unchanged within noise. The benefit is less allocation and GC pressure at high request rates, not per-call latency. - Behavior with built-in metrics enabled is unchanged. <details> <summary>Benchmark used (not committed)</summary> ```go func BenchmarkDMLTransactionMetricsDisabled(b *testing.B) { _, client, teardown := setupMockedTestServerWithConfig(&testing.T{}, ClientConfig{DisableNativeMetrics: true}) defer teardown() ctx := context.Background() stmt := NewStatement(UpdateBarSetFoo) run := func() { if _, err := client.ReadWriteTransaction(ctx, func(ctx context.Context, tx *ReadWriteTransaction) error { _, err := tx.Update(ctx, stmt) return err }); err != nil { b.Fatal(err) } } run() // warm up the session and channel b.ReportAllocs() b.ResetTimer() for i := 0; i < b.N; i++ { run() } } ``` Run on both commits, interleaved: `go test -run '^$' -bench DMLTransactionMetricsDisabled -benchmem -count 2 -benchtime 3000x .` (5 rounds per side), then `benchstat main.txt pr.txt`. </details>

fix(spanner): stop leaking endpointLatencyRegistry cleanup goroutine (#20416) Replace timer-driven cleanup with amortized inline sweeps guarded by an atomic timestamp. Importing spanner and closing clients now leave no endpoint latency registry cleanup goroutine behind. Fixes #14488

fix(spanner): update dynamic channel pool default configuration (#20080) Set DCP defaults to DCPMaxRPCPerChannel=25, DCPMinRPCPerChannel=15, DCPScaleDownCheckInterval=3m, DCPInitialChannels=4, DCPMaxChannels=10, DCPMinChannels=2. Internal Ref: go/dynamic-channel-pooling-non-sab

chore(spanner): generate private vtprotobuf copy of google.spanner.v1 under internal/vtpb (#20566) Configure a librarian internal copy of google/spanner/v1 for the spanner module The copy is a private, renamed version of the Spanner data-plane messages (proto package google.spanner.v1.vtinternal, files under google/spanner/v1/vtinternal) generated with protoc-gen-go-vtproto alongside protoc-gen-go. It contains messages only, no service or gRPC code. Renaming the proto package and file paths keeps protobuf-go's global registry free of conflicts, so the public and private copies can be linked into the same binary. This is groundwork for an optional, faster decoding path for query results. Keeping the vtprotobuf code in an internal package means: - no vt methods are added to the public spannerpb types, so users cannot depend on them; - nothing in the spanner package imports the copy yet, so applications do not link any vtprotobuf code; - vtprotobuf can be removed later without a public API change. The public spannerpb package is unchanged. Refs googleapis/librarian#7585