Line Protocol Writes and Flux Reads: Which Value Wins on Duplicate Timestamps Across InfluxDB Versions?

Short answer

In both InfluxDB 1.x and 2.x (OSS), a point is uniquely identified by its measurement, tag set, and timestamp. If you write two points with the same identity but different field values, the second write silently overwrites the first—effectively a "last write wins" strategy. Flux does not perform duplicate resolution at query time; it simply returns the value that was stored.

Resolution rule and whether 1.x and 2.x differ

The overwrite rule is a property of the data model, not the specific version. Both 1.x and 2.x use TSM-based storage, so the behavior is consistent across your migration. Two nuances matter:

• Same field key: The later write replaces the earlier value.
• Different field keys: The fields merge into a single point at that timestamp.

While the rule is consistent, the "last" write is determined by the order the server processes the requests. Because of client-side batching, network latency, or proxies, server processing order is not guaranteed to match the client-side send order.

Does writePrecision change what counts as a duplicate?

Only indirectly. writePrecision tells the server how to interpret the numeric timestamp in the line protocol, but InfluxDB stores everything at nanosecond resolution internally. So:

• Two writes that normalize to the same stored timestamp are duplicates; one overwrites the other.
• Two writes that differ after normalization coexist as separate points.

This is a common trap in mixed-precision fleets: a retry sent at second precision against an original written at nanosecond precision will not overwrite—it creates a second point nearby. A Flux query over that range will then return both.

Verifying which write survived

You do not need to inspect TSM files. Query the exact series and timestamp with Flux and compare the result against your candidate writes:

from(bucket: "metrics")
  |> range(start: 2026-10-14T08:00:00Z, stop: 2026-10-14T08:00:01Z)
  |> filter(fn: (r) => r._measurement == "cpu" and r.host == "a" and r._field == "value")

A narrow range around the single timestamp returns exactly the surviving value. A quick test confirms this on your deployment: write two lines with identical measurement/tags/timestamp but different values via the API, then run the query above—only the second value should appear.

Practical recommendation

Make retries idempotent: a retry should resend the identical value at the identical timestamp, so last-write-wins is harmless. If retries carry updated values and you need to keep both, add a distinguishing tag or field rather than relying on write order. Note: this covers OSS 1.x and 2.x. If your migration targets InfluxDB 3.x or Cloud, verify the deduplication behavior separately, as it is not covered by the same guarantees.