Jan Novak
ed59a4c384
Inject an option.WithLogger slog logger bridged to the zap sink via logr.ToSlogHandler with a V(1) shift, so the SDK's Debug-level "api request"/"api response" records (URL, headers, full payloads) appear only at --zap-log-level=5. Startup warning when active, since raw insert payloads include cloud-init user-data. Note WithLogger overrides GOOGLE_SDK_GO_LOGGING_LEVEL for this client. Co-Authored-By: Claude <noreply@anthropic.com>
1.6 KiB
1.6 KiB
Execution: GCP HTTP wire logging at V(5)
Plan: docs/plans/2026-08-11-1838-gcp-http-wire-logging-v5.md
- Step 1 —
wireLogger+option.WithLoggerwiring ininternal/provider/gcp/gcp.go - Step 2 — Tests (
TestWireLogger_gatesAtV5,TestWireLogger_infoLandsAtV1) - Step 3 — Live verification at
--zap-log-level=5(user, on cluster) - Step 4 — CHANGELOG entry (after live confirmation; batch with the two earlier pending entries: GCP V-logging, version stamp)
Steps 1–2
Went exactly as planned — the whole feature is ~10 lines of production code
because both halves already existed: the compute SDK logs full HTTP
request/response records at slog Debug to an injectable logger, and
logr.ToSlogHandler does the slog→logr bridging. The only real design
content is the level shift (base.V(1) + slog-Debug's +4 = V(5)) and the
startup warning line when V(5) is active (raw payloads include cloud-init
user-data, which the curated V(2) logging deliberately hides).
Worth noting for future readers:
option.WithLoggerdisablesGOOGLE_SDK_GO_LOGGING_LEVELfor this client (documented SDK precedence) —--zap-log-levelis now the only knob for GCP wire logs.- The V(5) check in
Newruns once at startup; that is sound because the zap level is fixed by flags at process start. - Added
TestWireLogger_infoLandsAtV1beyond the plan's table — it pins the shift arithmetic from the other side (slog Info → V(1)), so a future logr mapping change would fail loudly.
Verified with:
go test -race ./internal/provider/gcp/
go build ./... && go test ./...