Duplicate row insertion on retry in Pulsar IO JDBC sink

The goal is to achieve exactly‑once write semantics when a Pulsar IO JDBC sink retries a message after a transient failure.

Transactional producers bypass broker‑side deduplication, so relying on deduplicationEnabled=true does not prevent duplicate inserts on retry. The sink receives the same message again and, if the JDBC operation is a plain INSERT, each retry creates another row unless the sink implements its own deduplication or upsert logic.

Because Pulsar provides no built‑in idempotent consumer framework, the application must track processed message IDs or make the sink operation idempotent, but the appropriate pattern and configuration remain unclear.

What configuration or sink design ensures idempotent writes during retries? Is enabling broker‑side deduplication sufficient when using transactional producers? Should the JDBC sink use upsert or an external processed‑ID store to avoid duplicates?