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

We ingest metrics into InfluxDB through the HTTP API using line protocol, and we query the same data with Flux. Occasionally the same measurement, tag set, and timestamp is written more than once — for example when a client retries after a timeout. We need to know which value a Flux SELECT will return in that situation.

The constraint is that our deployment includes both InfluxDB 1.x and 2.x instances during a migration. Documentation and community reports suggest the duplicate-timestamp resolution rule differs between versions: in some cases the last write wins silently, in others the behavior depends on the storage engine or write path. We cannot rely on a single observed result from one version.

We also set writePrecision to seconds on some clients and nanoseconds on others, which may affect whether two points are even considered duplicates.

Questions:

1. What is the documented resolution rule when line protocol writes two points with identical measurement, tag set, and timestamp, and does it differ between InfluxDB 1.x and 2.x?
2. Does the configured writePrecision change which points are treated as duplicates at query time in Flux?
3. Is there a supported way to verify, per measurement, which write actually survived, short of inspecting TSM files directly?