elastic/elasticsearch · error · UnsupportedOperationException

deprecated fields not supported in [{parserName}] but got [{

Error message

deprecated fields not supported in [{parserName}] but got [{removedName}] at [{location}] which has been deprecated entirely

What it means

THROW_UNSUPPORTED_OPERATION.logRemovedField throws when the input uses a field that has been removed entirely (deprecated with no replacement) and parserName is non-null. Unlike renamed/replaced, there is no substitute field; the field is gone. parserName and location are included to aid correction.

Source

Thrown at libs/x-content/src/main/java/org/elasticsearch/xcontent/DeprecationHandler.java:71

                        + "] but got ["
                        + oldName
                        + "] at ["
                        + location.get()
                        + "] which has been replaced with ["
                        + currentName
                        + "]"
                );
            } else {
                throw new UnsupportedOperationException(
                    "deprecated fields not supported here but got [" + oldName + "] which has been replaced with [" + currentName + "]"
                );
            }
        }

        @Override
        public void logRemovedField(String parserName, Supplier<XContentLocation> location, String removedName) {
            if (parserName != null) {
                throw new UnsupportedOperationException(
                    "deprecated fields not supported in ["
                        + parserName
                        + "] but got ["
                        + removedName
                        + "] at ["
                        + location.get()
                        + "] which has been deprecated entirely"
                );
            } else {
                throw new UnsupportedOperationException(
                    "deprecated fields not supported here but got [" + removedName + "] which has been deprecated entirely"
                );
            }
        }
    };

    /**
     * Ignores all deprecations

View on GitHub (pinned to db6a809a66)

Solutions

Remove the field from the input entirely; it has no replacement.
If the capability is still needed, find the new API/field that supersedes it in release notes and migrate.
During a deprecation window, switch the handler to log instead of throw so callers can migrate gracefully.

Example fix

// before
{"include_type_name": true}  // removed field
// after: delete the field
{}

Defensive patterns

Strategy: validation

Validate before calling

// drop removed deprecated fields before strict parsing
Set<String> removed = Set.of("include_type_name");
removed.forEach(body::remove);

Try / catch

try {
    p.parse(parser, ctx);
} catch (UnsupportedOperationException e) {
    if (e.getMessage().contains("deprecated entirely")) {
        // remove the field entirely and retry
    }
}

Prevention

Strip fields known to be fully removed before strict parsing.
Track removals per version and validate input against the target version's allowed field set.
Use a logging handler during the deprecation window so callers can migrate before the strict cutover.

When it happens

Trigger: Strict parsing of a request containing a field that was fully removed in a prior version. Clients built against an old API sending a now-deleted field to a strict handler.

Common situations: Feature removals where the field has no successor. Forcing callers off a removed configuration knob.

Related errors

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