What causes "unable to convert [{}] to float" in elastic/elasticsearch?

Inspect the actual field value in the failing document (the message prints it in brackets) and correct the source data or upstream producer.

elastic/elasticsearch · error · IllegalArgumentException

unable to convert [{}] to float

Error message

unable to convert [{}] to float

What it means

Thrown by the ConvertProcessor's FLOAT enum constant when Float.parseFloat cannot turn the field's string form into a float. The processor delegates to Float.parseFloat, so any input that is not a parsable IEEE-754 float literal (including locale-specific decimal separators, currency symbols, or text) reaches this NumberFormatException->IllegalArgumentException wrapper. It surfaces during ingest pipeline execution on the document being indexed.

Source

Thrown at modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/ConvertProcessor.java:78

            }
        },
        DOUBLE {
            @Override
            public Object convert(Object value) {
                try {
                    return Double.parseDouble(value.toString());
                } catch (NumberFormatException e) {
                    throw new IllegalArgumentException("unable to convert [" + value + "] to double", e);
                }
            }
        },
        FLOAT {
            @Override
            public Object convert(Object value) {
                try {
                    return Float.parseFloat(value.toString());
                } catch (NumberFormatException e) {
                    throw new IllegalArgumentException("unable to convert [" + value + "] to float", e);
                }
            }
        },
        BOOLEAN {
            @Override
            public Object convert(Object value) {
                if (value.toString().equalsIgnoreCase("true")) {
                    return true;
                } else if (value.toString().equalsIgnoreCase("false")) {
                    return false;
                } else {
                    throw new IllegalArgumentException("[" + value + "] is not a boolean value, cannot convert to boolean");
                }
            }
        },
        IP {
            @Override
            public Object convert(Object value) {

View on GitHub (pinned to db6a809a66)

Solutions

Inspect the actual field value in the failing document (the message prints it in brackets) and correct the source data or upstream producer.
Add a script/grok processor before convert to strip non-numeric characters or normalize decimal separators.
Set the convert processor's 'ignore_missing: true' only if absence (not bad values) is the issue; for bad values use an 'on_failure' handler on the pipeline to route the document.
If the value legitimately exceeds float precision, switch the processor 'type' to 'double' instead of 'float'.

Example fix

// before - source field "price" = "12,99" (comma decimal)
{"convert": {"field": "price", "type": "float"}}
// after - normalize separator first, then convert
{"gsub": {"field": "price", "pattern": ",", "replacement": "."}},
{"convert": {"field": "price", "type": "float"}}

Defensive patterns

Strategy: validation

Validate before calling

// In a pipeline, pre-screen the field with a script processor before convert:
{"script": {"source": "if (ctx.price != null && (ctx.price =~ /^-?(?:0x[0-9a-fA-F]+|[0-9]*\.?[0-9]+(?:[eE][+-]?[0-9]+)?$/).matches() == false) { throw new Exception('bad float: ' + ctx.price) }"}}

Type guard

// painless type guard inside a script processor
boolean isFloatable(def v) { return v != null && (v instanceof Number || (v.toString() =~ /^-?[0-9]*\.?[0-9]+$/).matches()); }

Try / catch

// Configure pipeline on_failure to route convert failures to a DLQ instead of aborting:
{"on_failure": [{"index": {"index": "ingest-dlq"}}], "processors": [...]}

Prevention

Always pair convert processors with an on_failure handler that writes to a dead-letter index.
For user-provided data, normalize decimal separators and strip units in a prior gsub/script step.
Test pipelines against representative sample documents before applying them to production indices.

When it happens

Trigger: A pipeline with a 'convert' processor whose 'type' is 'float' is applied to a document whose source field value's toString() is non-numeric (e.g. "N/A", "12,5", "12.5.0", empty string). Also triggered for values that overflow Float range.

Common situations: Locale-formatted decimals written with a comma instead of a dot; non-numeric sentinel values like '-' or 'null' loaded from CSV/log shippers; schema drift where a previously numeric field starts carrying strings; unit suffixes such as '12.5kg'.

Related errors

AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/dd54082bb05d3fb2. Report an issue: GitHub.