🚨 Telegraf Error Guide: 'partial write: field type conflict' — Fix InfluxDB Type Clashes

Overview

InfluxDB rejects part of a write batch when an incoming field’s data type does not match the type already stored for that field in the current shard. Telegraf surfaces it as a partial write:

E! [outputs.influxdb] When writing to [http://influxdb:8086]: received error status code 400; partial write: field type conflict: input field "value" on measurement "temperature" is type float, already exists as type integer dropped=1

The critical detail is partial write and dropped=N: InfluxDB accepted the well-typed points in the batch and threw away only the conflicting ones. Data loss is silent and selective.

Symptoms

• partial write: field type conflict with dropped=N on every flush that includes the offending series.
• A dashboard panel for one measurement is patchy while everything else is fine.
• The conflict names a specific field and the two clashing types (float vs integer, or string vs float).
• The problem often starts right after a plugin upgrade, a new host, or a config change.

Common Root Causes

• Two sources emitting the same field with different types — e.g. one exporter sends value=1i (integer) and another sends value=1.0 (float).
• A value that is sometimes whole, sometimes fractional where Telegraf infers int for 5 and float for 5.5.
• A field that is numeric on some hosts and a string on others (e.g. "n/a" vs 42).
• Schema drift after an upgrade — a plugin changed the type it reports between Telegraf versions.
• The type is fixed for the life of a shard, so even after you fix the source, old shards keep rejecting until they roll over.

Diagnostic Workflow

Find the existing stored type so you know which side to change. Query the field keys and their types in InfluxDB:

influx -database telemetry -execute 'SHOW FIELD KEYS FROM "temperature"'

name: temperature
fieldKey  fieldType
--------  ---------
value     integer

Identify which input is emitting the other type. Dump what Telegraf produces without writing it:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter sensors

Look for value=23.4 (float) versus value=23i (integer trailing i). Pin the type with a converter processor so Telegraf always emits the stored type:

[[processors.converter]]
  [processors.converter.fields]
    float = ["value"]

Reproduce the conflict directly against InfluxDB to confirm the fix reconciles it:

curl -i -XPOST "http://influxdb:8086/write?db=telemetry" \
  --data-binary 'temperature value=23.4'   # float now matches

A 204 means the type now matches the shard. If the shard’s stored type is what you want to keep, converting the source is the whole fix; if you need to change the stored type, you must write into a new measurement or a new shard.

Example Root Cause Analysis

A fleet reported temperature.value as integer because early firmware only sent whole degrees. New firmware began sending decimals, so Telegraf inferred float, and every decimal reading was dropped with field type conflict. SHOW FIELD KEYS confirmed the stored type was integer. Because the operators wanted decimal precision going forward, they could not just convert to integer. They created temperature_v2 as the new measurement, applied a processors.rename for the new firmware, and let the old measurement age out by retention. Writes stopped being dropped, and dashboards were updated to union both measurements during the transition.

Prevention Best Practices

• Standardize field types at the edge with a processors.converter block so every source emits the same type for a shared field.
• Never mix numeric and string values in one field; route non-numeric sentinels ("n/a") to a tag or drop them with processors.regex.
• Treat InfluxDB field types as an immutable contract per measurement; version the measurement name when a type must change.
• Add a --test schema check to CI so a plugin upgrade that changes a field’s type is caught before deploy.
• Monitor Telegraf’s internal dropped-metric count so partial writes are visible immediately.

Quick Command Reference

# Show the stored type for a measurement's fields
influx -database telemetry -execute 'SHOW FIELD KEYS FROM "temperature"'

# See the type Telegraf emits (look for trailing i = integer)
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter sensors

# Force a consistent type
# [[processors.converter]] -> fields.float = ["value"]

# Reproduce the corrected write
curl -i -XPOST "http://influxdb:8086/write?db=telemetry" \
  --data-binary 'temperature value=23.4'

# Watch for conflicts live
journalctl -u telegraf -f | grep 'field type conflict'

Conclusion

A partial write: field type conflict means InfluxDB’s per-shard type contract was violated: one field is arriving as a different type than it was first stored as. Discover the stored type with SHOW FIELD KEYS, pin the source type with a converter processor, and if you actually need a new type, roll to a new measurement rather than fighting the immutable shard. Because these writes are partial, monitor dropped counts so the loss never goes unnoticed. For retention-related partial writes see the points beyond retention policy guide. More fixes in the Telegraf guides.