Does Dynatrace deduplicate writes when a custom plugin re-executes after a failure?

Short answer

No. Dynatrace does not provide documented server-side deduplication for measurements submitted by a retried custom OneAgent plugin execution. If a plugin fails partway through and re-executes on the next cycle, the platform ingests whatever the retry submits, and identical metric name + timestamp combinations can land as duplicate data points in your managed cluster. The idempotency mechanisms you're familiar with — request IDs on PurePath, stable eventId on the Events API, fingerprinting in problem detection — are caller-supplied or pipeline-specific features, not a general safety net for custom plugin output.

Likely explanation vs. confirmed facts

Confirmed: The deduplication you see in built-in paths works because the caller or the pipeline supplies a stable identity (request ID, eventId, fingerprint). Custom plugin executions have no equivalent documented identity mechanism inside the OneAgent ingestion path.

Likely, but verify for your release: A plugin retry re-runs the full plugin logic and the resulting measurements are ingested as-is, without suppression of points matching a prior failed run. This is the behavior consistent with how the platform treats plugin output, but deduplication internals can differ between SaaS and managed clusters and can change across releases without compatibility guarantees, so treat this as the safe assumption rather than a documented promise.

What to do in your plugin

Since the platform won't deduplicate for you, make the plugin idempotent:

• Deterministic timestamps: derive the measurement timestamp from the data itself (e.g., the source event time), not from the wall-clock time of execution. A retry then re-submits the same point rather than a new one. Note this only helps if the backend collapses identical timestamp+value points — which is not guaranteed — so don't rely on it alone.
• Checkpoint state: persist a high-water mark (last successfully processed offset/timestamp) on the host, and only emit measurements after it. On retry, the plugin resumes from the checkpoint instead of re-emitting.
• Stable identifiers for events: if the plugin pushes events, supply a deterministic eventId derived from the source data (e.g., a hash of entity + timestamp + type), mirroring the Events API idempotency contract.

Verifying duplicate behavior

There is no documented UI flag or API endpoint that retroactively merges or suppresses duplicates from plugin retries. To check whether you're affected:

1. In the Metric Browser, filter to the affected custom metric and inspect the window around a known plugin failure. Multiple data points at identical or near-identical timestamps within one retry interval indicate duplicate ingestion.
2. Correlate with the OneAgent plugin logs on the host — execution timestamps and exit codes tell you exactly when the failed run and retry occurred.
3. For events, send the same payload twice with a fixed eventId via the Events API in a test environment and confirm only one event appears; then repeat without an eventId to see the contrast.

One caveat for managed clusters

Because behavior can vary across managed releases, the only assumption worth building on is the conservative one: the caller (your plugin) owns idempotency. If you want a definitive statement for your exact cluster version, that's a question for Dynatrace support with your cluster build number — it changes the recommendation only if they confirm a version-specific dedup feature you could rely on instead.