sidecar: log the pgwire principal once on the session line

• Rebuilds pgwire session loggers with the discovered user, preventing duplicate principal keys.
• Verifies opened and closed JSON logs contain exactly one final principal.

sequenceDiagram
    actor Client as PostgreSQL Client
    participant Proxy as Sidecar Proxy
    participant PGWire as PGWire Negotiation
    participant Logger as Root Logger
    Client->>Proxy: Open connection
    Proxy->>Logger: Create anonymous context
    Proxy->>PGWire: Read startup message
    PGWire-->>Proxy: Return claimed user
    Proxy->>Logger: Rebuild final context
    Logger-->>Proxy: Single principal logger
    Proxy->>Logger: Log opened and closed

Rebuilding the session logger from the root is the best approach because slog attributes are append-only and cannot safely overwrite the earlier anonymous principal. Delaying principal attachment would complicate non-PostgreSQL and pre-negotiation logging, while handler-level duplicate suppression would introduce broad behavior for a localized issue.

Bug fix (1) +4 / -1

proxy.goRebuild pgwire logger with the final principal +4/-1

Rebuild pgwire logger with the final principal

• Recreates the session logger from the server’s root logger after pgwire reveals the claimed user. This preserves the session identifier while preventing the initial anonymous and final user principals from appearing together on lifecycle log lines.

sidecar/proxy/proxy.go

Tests (1) +119 / -0

proxy_test.goVerify one principal on session lifecycle logs +119/-0

Verify one principal on session lifecycle logs

• Adds a pgwire StartupMessage builder, synchronized log buffer, and duplicate-aware JSON token decoder. The regression test confirms both session-opened and deferred session-closed lines contain exactly one principal with the discovered user.

sidecar/proxy/proxy_test.go

Description

TestSessionLinesLogThePrincipalOnce ignores errors from Write, SetReadDeadline, ReadFull,
and Close. If deadline setup fails or network I/O is partial, the test can block or continue after
an incomplete exchange, obscuring whether the regression path ran.

Code

sidecar/proxy/proxy_test.go[R370-373]

+	c.Write(pgStartup("alice"))
+	c.SetReadDeadline(time.Now().Add(2 * time.Second))
+	io.ReadFull(c, make([]byte, len(pgStartup("alice"))))
+	c.Close()

Relevance

●●● Strong

Explicit I/O error handling is a deterministic reliability fix, consistent with recent accepted
test-safety feedback.

PR-#1809

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 1807206 requires errors from OS, execution, and I/O calls to be handled or
propagated. The added test invokes four network I/O operations without checking any returned error
or documenting why it is safe to ignore them.

Rule 1807206: Do not ignore errors from OS/exec/IO calls; handle or propagate them sidecar/proxy/proxy_test.go[370-373]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new regression test ignores errors returned by its connection write, deadline setup, response read, and close operations, allowing hangs or incomplete exchanges.

## Fix Focus Areas
- sidecar/proxy/proxy_test.go[370-373]

## Recommended Fix
Check each returned error and fail the test immediately with operation-specific context. Also verify the write and read byte counts, and treat any close error as a test failure unless explicitly documented as safe to ignore.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗