A county API extract times out occasionally. Retries must not double-write successful gold publishes. What design is appropriate?

Municipal jobs should retry transient API timeouts while keeping gold publishes idempotent so successful writes are not applied twice. County extracts that occasionally time out need task retries for resilience, but gold MERGE/upsert keys (or equivalent idempotent design) must ensure a retried DAG does not double-count fees, cases, or benefits already published. Retries without idempotency create silent duplication; idempotency without retries leaves every blip as a failed night.

Retrying the entire DAG including gold publish with no idempotent keys fails by concept: a timeout after a successful gold write can duplicate facts on retry. Disabling all retries and failing the night on a single timeout maximizes operational fragility for a known transient fault class. Truncating gold and reloading five years on every timeout is a destructive hammer that extends outage windows and risks inconsistent restores.

Exam caveat: idempotency keys must match the business grain of the gold fact; wrong keys can still upsert the wrong row even when retries are "safe." Operational check: simulate an API timeout after a successful gold write, retry the job, confirm gold row counts and aggregates do not double, and verify extract task retry metrics separately from publish success.