NumberFormatException During Indexing — Wrong Data Type in Numeric Field

Errors

The Error

Solr rejects documents during indexing with:

org.apache.solr.common.SolrException: ERROR: [doc=1125275] Error adding field
'kcal'='false' msg=For input string: "false"
Caused by: java.lang.NumberFormatException: For input string: "false"

The field name, document ID, and value will vary, but the pattern is always the same: a non-numeric value was sent to a numeric field.


What Is Actually Happening

DATA TYPE MISMATCH DURING INDEXINGYour Documentkcal = "false"String / Booleanschema.xmlkcal: pfloatExpects a numberNumberFormatExceptionFor input string: "false"Document REJECTED"false" / "true" / "N/A"Not a number"" / null / "none"Empty or non-numeric42 / 3.14 / 0Valid numbersFix your data before indexing, or change the field type in schema.xml to match your data.Solr rejects the entire document — not just the bad field.

Your schema.xml defines a field as numeric (pfloat, pint, plong, pdouble), but the data you are indexing contains values that are not numbers — strings like "false", "true", "N/A", "none", or empty strings.

Solr does not silently skip bad values. It rejects the entire document. If you are batch-indexing 1,000 documents and one has kcal=false, that document fails and is not indexed.


Common Causes

1. Boolean values in numeric fields

Your data source (database, CSV, API) has boolean fields (true/false) that end up in a Solr field typed as pfloat or pint. This is the most common case.

2. Placeholder strings in numeric fields

Your data has "N/A", "none", "null", "-", or empty strings where numbers are expected.

3. Schema/data mismatch after schema change

You changed a field from string to pfloat in your schema, but old data in your pipeline still sends string values.

4. Mixed data types in the same field

Some documents have valid numbers for the field, but others have strings. Solr does not do type coercion — every value must match the field type exactly.


How to Fix It

Option A: Clean your data before indexing

Filter or transform the data in your application before sending it to Solr:

# Python example — clean before indexing
value = doc.get("kcal", "")
if value in ("false", "true", "N/A", "none", "", None):
    doc["kcal"] = 0  # or remove the field entirely
else:
    doc["kcal"] = float(value)
// PHP example — clean before indexing
$value = $doc['kcal'] ?? '';
if (!is_numeric($value)) {
    $doc['kcal'] = 0; // or unset($doc['kcal']);
}

Option B: Change the field type in schema.xml

If the field genuinely contains mixed data types, change it to string in your schema.xml:

<!-- Before: numeric field that breaks on non-numeric values -->
<field name="kcal" type="pfloat" indexed="true" stored="true"/>

<!-- After: string field that accepts anything -->
<field name="kcal" type="string" indexed="true" stored="true"/>

Upload your updated schema.xml via the Opensolr Control Panel and re-index your data.

Note: Changing to string means you lose numeric range queries (kcal:[100 TO 500]) and numeric sorting. Only do this if the field is not used for numeric operations.

Option C: Skip the field for bad documents

Simply do not send the field when the value is invalid. Solr will index the document without that field (as long as the field is not required="true" in your schema):

// Document with valid kcal
{"id": "1", "title": "Apple", "kcal": 52}

// Document with no kcal — just omit the field
{"id": "2", "title": "Unknown food"}

How to Find the Bad Documents

Check your Solr error logs in the Error Audit — each rejected document shows the document ID ([doc=1125275]) and the exact field and value that caused the failure.

If you are bulk-indexing, send documents in small batches so you can identify which batch contains the bad data.