agent double-reported the same backup and the dedupe job failed

TL;DR

Double reporting happens when the agent emits a result per processing attempt instead of per backup event, and downstream dedupe keys on something unstable like report time. Assign each backup event its product job identifier as the report key, store sent report keys durably, and make the reporting endpoint or file append idempotent so retries update rather than duplicate.

agent double-reported the same backup and the dedupe job failed

Use this when

• Dashboards show the same backup twice with slightly different report details.
• Dedupe jobs downstream fail or need manual cleanup after agent retries.
• Duplicates cluster around runs where the agent restarted or retried reporting.

Not for this skill when

• Two genuinely different backups share a name and look like duplicates. Naming discipline problem.
• The scheduler ran the test twice, creating two real events. Earlier stage.

Steps

1. Trace a duplicated report pair back to their job identifiers and emission times. Verify: both reports describe the same product job
2. Change report identity to the product job identifier plus the outcome version, generated at the source. Verify: retries produce the identical key in tests
3. Persist sent keys in the agent state so restarts do not resend as new. Verify: a restarted agent does not duplicate a sent report
4. Make the downstream consumer upsert by that key instead of appending blindly. Verify: a duplicate delivery updates in place
5. Replay a day of reports through the new path. Verify: counts reconcile exactly with product job counts

Variant phrasings

duplicate report idempotency key agent dedupe

The idempotency phrasing.

same backup reported twice dashboard duplicate

The symptom variant.

agent reporting retry duplicates fix upsert

The upsert wording.

Compatibility: Agents reporting backup outcomes to dashboards, data warehouses and ticketing systems via APIs and file drops.

Why it happens

Retries are healthy; non-idempotent reporting makes them harmful. Any agent that can crash between doing work and reporting it will eventually double-report if identity is invented at report time. Anchoring identity in the source system job identifier, the one thing that cannot differ between attempts, is the whole fix.

Edge cases / pitfalls

• Dedupe windows downstream are a bandage. Fix identity at the source and keep downstream dedupe as backup.
• Outcome corrections are legitimate second reports. Version them under the same key rather than suppressing them.
• Reconcile counts weekly against the backup product. Drift means identity is still leaking somewhere.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gZG2sVbevVzYa52XB5a-Kg