[Privacy/Observability] Keep owner-scoped resource identifiers out of ETL failure logs

[seonghobae]

Buyer / operability gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 uses the shared EtlApiProblemHandler for both synchronous ETL and owner-scoped durable-job controllers. Every covered failure historically logged request.getRequestURI(). For durable-job resources that URI contains the opaque job_record_id, so ordinary WARN/ERROR diagnostics acquired per-job high-cardinality resource identifiers even though the public HTTP Problem Details body is deliberately bounded and non-sensitive.

This is narrower than #182's base logging/sampling-profile work. #182 already requires ordinary logs/spans not to key on job IDs. This issue closes the concrete shared-handler boundary without changing response ProblemDetail.instance, authorization, controller routing, payload handling, or the local debug profile.

RCA

• Immediate cause: handleRequestFailure, handleUnreadableBody, handleTransientTargetFailure, handleTargetFailure, and handleUnexpectedFailure interpolated the raw request URI into ordinary logs.
• Technical root cause: client-facing resource identity and operator failure classification were coupled even though resource identity is unnecessary for distinguishing ETL failure classes.
• Control failure: controller tests proved response confidentiality but did not capture logs for owner-scoped resource paths.
• Risk: durable job IDs became unnecessary high-cardinality log dimensions and could be exported to centralized logs/support bundles, contradicting [Operability/Privacy] Separate local-debug observability from production-safe defaults #182's finite-cardinality/privacy contract.

Live implementation state — active PR #219

Draft PR #219, branch privacy/etl-problem-log-resource-id-622e5e6, is the bounded direct-develop owner for this issue.

RED

Test-only source 1679d0c9ad99297ba710425e700fe68c21101dd4 added EtlApiProblemHandlerLoggingTest before production changed. Hosted CI 31366659260, macOS job 93386394718, checked out synthetic merge 30ccf21c5fcde284385f9d348b35c3020f9a480a, compiled production/tests successfully and ran 276 ETL tests with exactly one failure, zero errors/skips. The failing log was:

ETL target failure path=/api/etl/jobs/0198f4cf-41c8-7f52-9e5d-private-job-marker ...

The new assertion failed only because the unique owner-scoped resource marker was present. This is valid RED at the real handler/logging boundary, not setup/import/fixture/dependency failure.

GREEN candidate

Exact current candidate 79e8e4e7d593665c99d94dfc35fe842c1e5c749f is exactly one fast-forward commit over the RED head and changes only EtlApiProblemHandler.java. It removes request-URI transport from all covered ordinary log calls while preserving stable failure/error classifications and existing exception-type metadata. RFC 9457 ProblemDetail.instance still uses the request URI, so client-visible response semantics remain unchanged.

The publication comparison is ahead 1 / behind 0, merge base exactly the RED head; no unrelated branch movement was incorporated. Current-head CI/security/SAST are running and are not counted as passing until terminal.

Acceptance / shared boundaries

• the current-head captured-output test must be GREEN while retaining stable ETL failure classification;
• synchronous and durable-job HTTP responses remain unchanged, including instance;
• no payload, principal, idempotency key, hash, lease ID, SQL, exception message or raw body is introduced;
• [Operability/Privacy] Separate local-debug observability from production-safe defaults #182/[Documentation] Close canonical architecture coverage and live traceability gaps #159 should index the concrete boundary during the next safe canonical reconciliation;
• accepted literal-source execution/security evidence, complete dependency/vulnerability evidence ([Security evidence] Fail closed when Trivy cannot resolve Maven BOM-managed dependency versions #196), non-vacuous applicable coverage ([Quality gate] Make JaCoCo fail closed when production class selection is empty #162/fix(coverage): make JaCoCo production gate non-vacuous #164/[Quality evidence] Extend non-vacuous 100% coverage to every owned production module #205), zero valid unresolved findings and qualifying independent review remain separate protected-merge gates.

Current classification: active_pr via #219. Nothing is implemented_on_develop until protected integration and protected-develop acceptance.