Add structured JSON request and payment logging

[AnkanMisra]

Summary

Add structured JSON request and payment logging to the Go gateway while preserving current correlation ID behavior and avoiding sensitive data leaks.

Current State

The gateway currently uses Gin logging, correlation IDs, and targeted log.Printf calls. That is useful for local debugging but not enough for production log querying, alerting, or payment-flow analytics.

Desired Behavior

• Add structured JSON logs for gateway requests and important payment outcomes.
• Include stable fields such as timestamp, level, method, path, status, duration, client IP, correlation/request ID, and safe payment metadata.
• Do not log signatures, private keys, API keys, Redis URLs, raw verifier internals, provider response bodies, or wallet secrets.
• Keep logs compatible with existing correlation ID headers and sanitized public error behavior.
• Add configuration only where needed, such as log format/level.

Acceptance Criteria

• Gateway request logs are emitted as structured JSON when enabled/configured.
• Logs include latency, status, route, correlation ID, and safe payment verification outcome fields.
• Existing sensitive fields are redacted or omitted.
• Log level behavior is documented and tested.
• Tests cover success, 402, invalid signature, replay, upstream failure, and no-secret leakage.
• Gateway README and deployment/support docs explain the logging behavior.

Replaces #14, whose examples used old chain defaults and did not account for the current correlation/error handling already in place.

[VarshithaChettipalli]

Hi @AnkanMisra, I'd like to work on this issue. Could you please assign it to me? I’ve reviewed the requirements and will add the route/navigation consistency test as described. Thanks!

[aayushprsingh]

Hi, I am a GSSoC 2026 contributor and would like to work on this. Please assign it to me!

Here's how I'm thinking of approaching this:
I will configure a JSON logging handler (such as zerolog or Gin's json logger middleware) inside the Go server routes. The logger will emit structured entries containing timestamp, request duration, status, path, and correlation IDs. I'll redact sensitive keys and webhook secrets, and write tests ensuring success/fail logs contain the expected fields without leaks.

[AnkanMisra]

@aayushprsingh go for it

[AnkanMisra]

Implementation status against the in-flight work (PR #192 / branch gssoc-fix-192).

Done:

• JSON logs emitted when LOG_FORMAT=json — JSONLoggerMiddleware in gateway/middleware.go:340-377, wired in gateway/main.go:270-274.
• Entry includes latency, status, route, method, client IP, correlation ID, cache status, and payment fields — JSONLogEntry (middleware.go:324-338); cache_status set in gateway/cache.go.
• Secret redaction — sanitizeErrorString (gateway/errors.go) scrubs OpenRouter keys and 64-hex secrets; covered by TestJSONLoggerMiddleware_Sanitization.

Still open per the acceptance criteria:

• Docs — no LOG_FORMAT/logging section in gateway/README.md or deployment docs.
• Failure-path payment fields — payment_status="success"/payer are set in handleSummarize, but no production path sets payment_status="failed" / payment_error on rejection, so failed-payment outcomes won't populate those fields in real logs. (Note: the working tree adds a guard so respondError no longer clobbers a prior success; the failed-state setter still needs wiring.)
• Test matrix — the JSON-logger tests assert a synthetic 200 + sanitization 500. The 402 / invalid-signature / replay / upstream-failure cases are exercised at the HTTP layer but don't assert the resulting JSONLogEntry fields.
• Log-level behavior documented + tested — level is derived from status, but there's no documentation of it.

Suggest keeping this open until #192 merges, then verifying the four items above.