elastic/elasticsearch · error · ElasticsearchParseException

Error parsing document in field [{}]

Error message

Error parsing document in field [{}]

What it means

ElasticsearchParseException wrapping any non-ZeroByteFileException thrown by Tika while parsing the attachment bytes. The field name is passed as the argument so the error points at the offending source field. This is the generic catch-all for corrupt, truncated, password-protected (other than public-key), or unsupported-format documents.

Source

Thrown at modules/ingest-attachment/src/main/java/org/elasticsearch/ingest/attachment/AttachmentProcessor.java:232

            indexedCharsValue = ingestDocument.getFieldValue(indexedCharsField, Integer.class, true);
            if (indexedCharsValue == null) {
                // If the field does not exist we fall back to the global limit
                indexedCharsValue = this.indexedChars;
            }
        }

        Metadata metadata = new Metadata();
        if (resourceNameInput != null) {
            metadata.set(TikaCoreProperties.RESOURCE_NAME_KEY, resourceNameInput);
        }
        String parsedContent = "";
        try {
            parsedContent = TikaImpl.parse(input, metadata, indexedCharsValue);
        } catch (ZeroByteFileException e) {
            // tika 1.17 throws an exception when the InputStream has 0 bytes.
            // previously, it did not mind. This is here to preserve that behavior.
        } catch (Exception e) {
            throw new ElasticsearchParseException("Error parsing document in field [{}]", e, field);
        }

        if (properties.contains(Property.CONTENT) && Strings.hasLength(parsedContent)) {
            // somehow tika seems to append a newline at the end automatically, lets remove that again
            additionalFields.put(Property.CONTENT.toLowerCase(), parsedContent.trim());
        }

        if (properties.contains(Property.LANGUAGE) && Strings.hasLength(parsedContent)) {
            // TODO: stop using LanguageIdentifier...
            LanguageIdentifier identifier = new LanguageIdentifier(parsedContent);
            String language = identifier.getLanguage();
            additionalFields.put(Property.LANGUAGE.toLowerCase(), language);
        }

        addAdditionalField(additionalFields, Property.DATE, metadata.get(TikaCoreProperties.CREATED));
        addAdditionalField(additionalFields, Property.TITLE, metadata.get(TikaCoreProperties.TITLE));
        // These two were supposedly removed in tika 2, but some parsers seem to still generate them:
        addAdditionalField(additionalFields, Property.AUTHOR, metadata.get("Author"));

View on GitHub (pinned to db6a809a66)

Solutions

  1. Inspect the chained cause for the Tika-specific failure reason
  2. Validate/repair the source document out-of-band before ingest
  3. Add on_failure handling in the pipeline to route failed docs to a dead-letter index

Example fix

// before
PUT _ingest/pipeline/attach
{"processors":[{"attachment":{"field":"data"}}]}
// after: route parse failures instead of failing the bulk request
{"processors":[{"attachment":{"field":"data","on_failure":[{"index":{"index":"attach-failures","pipeline":"_none"}}]}}]}
Defensive patterns

Strategy: try-catch

Try / catch

try { ingest(attachmentPipeline, doc); }
catch (ElasticsearchParseException e) {
    Throwable cause = e.getCause(); // Tika-specific
    routeToFailureIndex(doc, cause);
}

Prevention

When it happens

Trigger: TikaImpl.parse throws a TikaException/IOException for a malformed, truncated, or unsupported file; the catch(Exception) in execute re-wraps it. Zero-byte files are intentionally swallowed separately.

Common situations: Corrupt PDFs/Office docs; truncated uploads; password-protected Office files; formats Tika cannot handle; encoding issues in transit.

Related errors

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