From acf368b6fe290f44157ada79448673ab11808f7c Mon Sep 17 00:00:00 2001 From: brother7 <7brother7@gmail.com> Date: Sun, 16 Aug 2026 22:41:55 +0800 Subject: [PATCH] docs: record Go RDS TLS diagnosis --- .../20260816-diagnose-go-rds-tls-9c4a7e21.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 .project-docs/30-worklog/tasks/20260816-diagnose-go-rds-tls-9c4a7e21.md diff --git a/.project-docs/30-worklog/tasks/20260816-diagnose-go-rds-tls-9c4a7e21.md b/.project-docs/30-worklog/tasks/20260816-diagnose-go-rds-tls-9c4a7e21.md new file mode 100644 index 0000000..38a0676 --- /dev/null +++ b/.project-docs/30-worklog/tasks/20260816-diagnose-go-rds-tls-9c4a7e21.md @@ -0,0 +1,97 @@ +# Task: Diagnose Go RDS TLS startup failure + +## Identity + +- Task ID: 20260816-diagnose-go-rds-tls-9c4a7e21 +- Mode: Feature +- Branch: main +- Worktree: D:\Datas\OthersProjects\NianAIGC +- Base commit: bb50d06d1da67556571eb5e0fdb7312339842e71 +- Owner: codex +- Status: Ready for Integration + +## Scope + +- Diagnose the Go API startup failure whose root error is PostgreSQL `server + refused TLS connection` during first-super-administrator account listing. +- Verify the repository TLS defaults and ACK Secret contract without reading + or exposing production credentials. +- Keep the task diagnostic-only; do not change application behavior or mutate + the live ACK/RDS environment without cluster access and explicit operational + execution. + +## Intent And Constraints + +- Build a deterministic local PostgreSQL wire-protocol feedback loop that + exercises the real Go administration list path. +- Separate confirmed protocol behavior from the unverified live RDS control + plane setting. +- Prefer verified TLS for production; document `sslmode=disable` only as a + deliberate plaintext fallback when the operator accepts that tradeoff. +- Redact credentials and delete all temporary diagnostic code before finish. + +## Outcome + +- Confirmed the Go PostgreSQL configuration defaults to `verify-full` when + `DATABASE_URL` omits `sslmode`; the checked-in Secret example also specifies + `verify-full` and an RDS CA path. +- Reproduced the exact production error chain against a local PostgreSQL + protocol endpoint that returns `N` to `SSLRequest`: `list accounts` -> `list + administration accounts` -> `tls error (server refused TLS connection)`. +- Re-ran the identical administration query path against the same endpoint + with `sslmode=disable`; it passed. This isolates the failure to a mismatch + between client TLS mode and endpoint TLS capability, before credentials, + grants, schema, or bootstrap creation are evaluated. +- The most likely live cause is that the RDS instance/selected connection + address does not have SSL enabled while the deployed `DATABASE_URL` requests + verified TLS. Wrong endpoint/port or a TLS-refusing intermediary remain + lower-probability alternatives until checked from the Go Pod/RDS console. +- No product source, deployment manifest, or canonical project-memory file was + changed. The temporary diagnostic test was deleted. + +## Verification + +- RED: `go test ./internal/application -run + TestDiagnosticListAccountsAgainstTLSRefusingEndpoint -count=1 -v` reproduced + the exact `server refused TLS connection` error on the production query path. +- GREEN: with diagnostic mode set to `disable`, the same command and fake + endpoint passed. +- A credential-free SSLRequest probe to the real RDS host timed out from this + workstation; this is consistent with a private/VPC endpoint but does not + establish the RDS SSL setting. +- `kubectl config current-context` reported no configured context, so no live + Secret, Pod DNS result, or RDS endpoint was inspected or mutated. +- Alibaba Cloud's current RDS PostgreSQL documentation confirms that SSL must + be enabled for SSL-mode connections, `disable` is the non-SSL client mode, + and enabling/changing the protected address restarts the instance with a + minute-level interruption risk. + +## Follow-ups + +- In the RDS console, verify whether SSL is enabled and whether the protected + connection address exactly matches the host used by the Go Pod. +- Recommended production repair: enable RDS SSL for that address, mount the + downloaded CA as `zhinian-rds-ca`, retain `sslmode=verify-full`, update the + Go database Secret, and restart/smoke the Go Deployment. +- Temporary recovery alternative: explicitly use `sslmode=disable` in the Go + `DATABASE_URL`, accepting plaintext database transport inside the network, + then restart and verify the Deployment. +- After TLS negotiation succeeds, separately validate credentials, grants, + migrations 0001/0002, and super-administrator bootstrap. + +## Promotion Candidates + +- Target: production RDS validation evidence and deployment troubleshooting + guidance. + Proposal: record the live RDS SSL state/protected address and add a + credential-free SSLRequest check before deploying a `verify-full` database + URL. + Evidence: the Go startup failure and deterministic RED/GREEN protocol loop + recorded above. + Future impact: prevents fail-closed Go startup from being mistaken for an + account/bootstrap defect when the endpoint refuses TLS. + Semantic conflicts: none; this strengthens existing RDS-001/RDS hardening + commitments. + Human confirmation required: no for evidence/runbook promotion; enabling or + disabling production RDS SSL remains an operator decision because it can + restart the instance or weaken transport security.