elastic/elasticsearch · error · IllegalArgumentException
The input {} is not valid JSON and the {} parameter is true
Error message
The input {} is not valid JSON and the {} parameter is true What it means
Thrown by JsonProcessor.apply (inside the strictJsonParsing branch) when parser.nextToken() throws an IllegalArgumentException after the first token has already been read. This means the first token parsed OK but a subsequent token violated JSON grammar — strict mode wraps the cause and reports the original fieldValue. IllegalArgumentException with cause.
Source
Thrown at modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/JsonProcessor.java:132
throw new IllegalArgumentException("cannot read binary value");
}
if (strictJsonParsing) {
String errorMessage = Strings.format(
"The input %s is not valid JSON and the %s parameter is true",
fieldValue,
STRICT_JSON_PARSING_PARAMETER
);
/*
* If strict JSON parsing is disabled, then once we've found the first token then we move on. For example for the string
* "123 \"foo\"" we would just return the first token, 123. However, if strict parsing is enabled (which it is by default),
* then we check to see whether there are any more tokens at this point. We expect the next token to be null. If there is
* another token or if the parser blows up, then we know we had invalid JSON and we alert the user with an
* IllegalArgumentException.
*/
try {
token = parser.nextToken();
} catch (IllegalArgumentException e) {
throw new IllegalArgumentException(errorMessage, e);
}
if (token != null) {
throw new IllegalArgumentException(errorMessage);
}
}
return value;
} catch (IOException e) {
throw new IllegalArgumentException(e);
}
}
public static void apply(
Map<String, Object> ctx,
String fieldName,
boolean allowDuplicateKeys,
ConflictStrategy conflictStrategy,
boolean strictJsonParsing
) {View on GitHub (pinned to db6a809a66)
Solutions
- Fix the producer to emit a single valid JSON value in the field.
- If trailing content is expected, set "strict_json_parsing": false (note: only the first token will then be used).
- Pre-trim the field to a clean JSON value before the json processor.
Example fix
// before
{"json": {"field": "raw", "target_field": "parsed"}}
// data: raw = '123 "extra"'
// after
{"json": {"field": "raw", "target_field": "parsed", "strict_json_parsing": false}} Defensive patterns
Strategy: validation
Validate before calling
// Pre-check: parse and verify exactly one token with strict rules
try (XContentParser p = JsonXContent.jsonXContent.createParser(
XContentParserConfiguration.EMPTY, value)) {
p.nextToken();
if (p.nextToken() != null) throw new IllegalArgumentException("not a single JSON value");
} catch (IOException ioe) { /* invalid */ } Try / catch
try {
JsonProcessor.apply(value, allowDup, true);
} catch (IllegalArgumentException e) {
if (e.getMessage().contains("not valid JSON")) {
// retry with strict_json_parsing=false or route to failure store
} else throw e;
} Prevention
- If your data legitimately has trailing tokens, set strict_json_parsing=false.
- Validate producer output emits a single JSON value per field.
- Add unit tests for representative field values before deploying the pipeline.
When it happens
Trigger: strict_json_parsing=true (default) and the input string starts with a valid JSON token but contains trailing garbage. E.g. "123 abc" parses '123' then fails on 'abc'.
Common situations: Concatenated JSON values in one field, partial JSON due to truncation, log-line prefixes/suffixes around the JSON payload, or producer bugs emitting multiple values.
Related errors
- Provided Grok expressions do not match field value: [{}]
- cannot read binary value
- <wrapped IOException>
- cannot add non-map fields to root of document
- field [{}] does not contain value_split [{}]
AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12).
Data as JSON: /api/errors/55c29e09baba049e.
Report an issue: GitHub.