[CDC API integrity] Fail closed when PostgreSQL source SPI receives ignored per-call configuration

[seonghobae]

Contract defect

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 exposes CdcSourceConnector.validate(Map<String,String>) as the source-configuration validation boundary and start(config) as the control surface. The production PostgresDebeziumCdcSource historically accepted any non-null map and then delegated to CdcService.start(), whose live Debezium configuration is built from deployment environment variables. Caller-supplied host/slot/credential/include-list values were therefore silently ignored.

That is an API-integrity defect: a caller can believe a supplied configuration was validated/applied even though it cannot affect the running source. Silent ignore is worse than an explicit unsupported boundary because it can route capture from an unintended deployment-configured database while the caller believes a different source was selected.

RCA

• Immediate cause: protected PostgresDebeziumCdcSource.validate checked only config != null.
• Technical root cause: the generic SPI was introduced before the live PostgreSQL adapter gained per-call configuration ownership; the adapter delegates lifecycle but not configuration.
• Systemic/control failure: prior tests proved empty-map delegation only and did not assert that non-empty caller configuration cannot be silently discarded.

Smallest safe remedy

Until the adapter is actually wired to a reviewed per-call configuration model, fail closed for non-empty maps with a stable, non-sensitive exception. Preserve Map.of()/empty-map delegation to the existing deployment-owned CdcService configuration. Do not invent database credentials or partially translate only some keys.

This is intentionally narrower than redesigning the entire source SPI. A future implementation may replace the rejection only when caller-supplied configuration is fully validated and becomes the authoritative Debezium input.

Live implementation state — active PR #239

Draft PR #239, branch fix/postgres-spi-config-truth-622e5e6, now owns this bounded repair.

• protected/live base: develop@622e5e6c3d534f230c390f10e3832efadfc01825;
• fail-first source: 9b98a3b74274c9488422638f2eca7640a34f8057;
• exact current GREEN source: 75065b5c675408f69b0eab918d58fef991950e0f;
• current synthetic merge preview: 2a369886794b7d031ba952ac38ad6ceb2375d230;
• exact live-base comparison: two commits ahead, zero behind, merge base exactly protected develop;
• Draft / mergeable: true / true;
• formal reviews: none;
• unresolved review threads: zero.

RED

CI 31391184511, macOS job 93463055955, compiled normally and reached the real PostgresDebeziumCdcSource.start(config) boundary on synthetic merge ab39fd93fae3456cbeb5cbf6d7b55d2a9827f355. ETL passed 275/275. CDC ran 107 tests with exactly the new configuration test failing and zero errors/skips because production threw no IllegalArgumentException for a non-empty credential-like map. This is valid development RED rather than setup/import/dependency failure.

GREEN

Exact current source 75065b5c675408f69b0eab918d58fef991950e0f:

• rejects null as before;
• rejects every non-empty per-call map before service lookup/start;
• emits a stable rejection message containing neither key nor value;
• preserves empty-map delegation to deployment-configured CdcService;
• documents the deployment-owned configuration boundary in public Javadocs.

All exposed current-head aggregates are terminal-success: CI 31392884219, Dependency Review 31392881274, CycloneDX SBOM 31392878898, SAST Semgrep 31392877894, and Security Scan 31392877892. CI macOS job 93468612634 checked synthetic merge 2a369886...; the full reactor completed BUILD SUCCESS, including ETL 275/275, CDC 107/107 and the focused configuration test 1/1.

Remaining acceptance boundary

This issue remains open because active PR behavior is not shipped truth. Current hosted proof is synthetic-merge development evidence rather than accepted literal-source proof. The same CI still reproduces the inherited Analyzed bundle 'etl-service' with 0 classes JaCoCo false-green; #162/#164 and #205 own non-vacuous applicable/repository-wide coverage, and #196 owns dependency-resolution/scanner completeness. No qualifying independent non-author formal approval exists on #239's unchanged current head.

TDD acceptance

1. Fail-first test reaches the real PostgresDebeziumCdcSource.start(config) boundary with a non-empty map and proves protected code accepts/ignores it. Satisfied as development RED on fix(cdc): reject ignored PostgreSQL source SPI config #239.
2. GREEN rejects every non-empty per-call map before CdcService interaction, with a stable message that does not echo keys or values. Satisfied on fix(cdc): reject ignored PostgreSQL source SPI config #239 current source.
3. validate(Map.of()) and start(Map.of()) preserve current deployment-owned behavior. Satisfied by focused + existing lifecycle tests on the current candidate.
4. Null configuration remains rejected. Preserved by production validation contract.
5. Public Javadoc clearly states that the live PostgreSQL adapter is deployment-configured and accepts only an empty per-call map. Satisfied on fix(cdc): reject ignored PostgreSQL source SPI config #239 current source.
6. Focused/full CDC and current CI/security/dependency/SBOM gates regenerate on the current head. Current aggregates are green, but literal-source, complete scanner, non-vacuous coverage and independent-review gates remain separate and non-passing.

Close this issue only after the accepted implementation is integrated into protected develop and protected-develop acceptance confirms the invariant. MySQL/SQL Server scaffold-retirement work remains separate.

[seonghobae]

Protected develop@b50ba3156bbcbfdc12f3125dec0d34201c07bd8f now contains the accepted #238 invariant from merged PR #300 (cc0cf39b91c2a8829f93a38172d5d85066ae6d2). Fresh source inspection confirms PostgresDebeziumCdcSource.validate rejects null and every non-empty per-call map with the stable non-sensitive error before service lookup, while start(Map.of()) still delegates to the deployment-configured CdcService. The integrated PostgresDebeziumCdcSourceConfigurationTest proves credential-like values and keys are not echoed, invalid input causes no service interaction, null fails before provider lookup, and empty configuration still starts the live service. Later protected commits through b50ba315... leave both production and regression-test blobs present. The issue acceptance boundary is therefore implemented on protected develop; broader scanner/coverage/review controls remain independently tracked and do not reopen this bounded API-integrity defect.