[Connector integrity] Reject duplicate CDC connector IDs instead of silently replacing registrations

[seonghobae]

Product/security integrity gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 stores CDC source and target registrations in ID-keyed LinkedHashMaps and currently implements both CdcSourceRegistry.register(...) and CdcTargetRegistry.register(...) as unconditional byId.put(connector.id(), connector).

For sources, Spring beans are discovered with ObjectProvider<CdcSourceConnector>.orderedStream() and registered in sequence. A duplicate connector ID therefore silently lets the later bean replace the earlier implementation. For targets, public in-process registration can likewise replace an existing target. The configured connector ID is an authority selector; silently changing which implementation owns that ID makes startup order or accidental duplicate beans decide execution semantics.

Status: known_gap; bounded fail-closed repair is source-local and does not require credentials, external services, or cross-repository writes.

RCA

• Immediate cause: duplicate IDs use ordinary map replacement semantics.
• Technical root cause: connector identity uniqueness is treated as a map implementation detail instead of a validated registry invariant.
• Systemic/control cause: current registry tests verify presence/discovery but do not prove duplicate registration fails closed.
• Risk: a duplicate/misconfigured connector can shadow a trusted implementation, make find(id) depend on registration order, and cause status/discovery to describe a different implementation than operators expected.

Smallest remediation

Make duplicate registration a deterministic startup/configuration error:

• reject null connector or blank connector ID;
• use an explicit duplicate-ID check / putIfAbsent and throw a stable IllegalArgumentException (or a narrower reviewed configuration exception) naming only the non-secret connector ID;
• preserve successful unique registration order and fallback behavior;
• do not silently choose first/last, add priority semantics, or mutate IDs to make duplicates coexist.

A future plugin-priority model, if ever needed, requires an explicit ADR and must not be smuggled in as map ordering.

TDD / acceptance

RED first against the actual registries. Final acceptance must prove:

1. two source connectors with the same ID fail deterministically rather than replacing one another;
2. registering a target with an existing ID fails deterministically;
3. unique registrations remain discoverable in stable insertion order;
4. an empty Spring/test source registry still installs the intended PostgreSQL fallback exactly once;
5. blank/null connector identities fail before map mutation;
6. error text contains no connector config, credentials, payloads or exception-chain diagnostics;
7. full CDC tests and current dependency/SBOM/SAST/security evidence remain intact;
8. accepted source-identity and non-vacuous coverage controls are satisfied before protected integration.

Writer / scope boundary

Keep this slice limited to CDC registry identity semantics plus focused tests. Do not combine MySQL/SQL Server discovery retirement (#158/#163), generic target-SPI redesign, connector credentials, or the broader target-scaffold lifecycle (#153).

[seonghobae]

2026-08-10 TDD implementation progress — Draft PR #201

#201 now carries the bounded fail-closed registry repair from protected develop@622e5e6c3d534f230c390f10e3832efadfc01825.

• RED source f2683286c4a768ead11da0895a511ab2bec9af88: current registries reached production and all four new identity tests failed because duplicate/blank IDs were silently accepted.
• GREEN source 28b01de58d0c24cec864ef63bd9b9f3697c936d1: source/target register(...) now reject null, blank and duplicate identities, use putIfAbsent for uniqueness, retain source fallback and registration order, and document the identity-authority contract.
• CI 31349387128: synthetic integration tree 2399bb077ecf1bebd3d127611a07e56ef6b63fdb, CdcRegistryIdentityTest 4/4 green, CDC 110/110 green, ETL 275/275 green, full reactor success on hosted matrix.
• Dependency Review 31349387080, SBOM 31349387115, and SAST 31349387078: success.
• Security Scan 31349387076: aggregate green but not accepted as complete security evidence because hard Trivy is synthetic-source and warns that Maven dependency versions cannot be completely resolved ([Security evidence] Fail closed when Trivy cannot resolve Maven BOM-managed dependency versions #196).
• inherited JaCoCo still analyzes zero ETL production classes on this tree ([Quality gate] Make JaCoCo fail closed when production class selection is empty #162/fix(coverage): make JaCoCo production gate non-vacuous #164), so aggregate CI is not valid non-vacuous 100% owned-production coverage evidence.
• formal reviews remain absent and unresolved review threads are zero.

Keep this issue open until #201 integrates through accepted source/security/coverage/review controls. #202 remains a separate target-capability/API modeling gap and is not part of this uniqueness repair.