elastic/elasticsearch · error · UnsupportedOperationException

deprecated fields not supported here but got [{removedName}]

Error message

deprecated fields not supported here but got [{removedName}] which has been deprecated entirely

What it means

logRemovedField, parserName-null variant: a fully-removed deprecated field is used under THROW_UNSUPPORTED_OPERATION on an unnamed parser, so the message omits parser context. Identical semantics to 871 (removed, no replacement) but for parsers without a parserName.

Source

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

                    "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
     */
    DeprecationHandler IGNORE_DEPRECATIONS = new DeprecationHandler() {
        @Override
        public void logRenamedField(String parserName, Supplier<XContentLocation> location, String oldName, String currentName) {

        }

        @Override
        public void logReplacedField(String parserName, Supplier<XContentLocation> location, String oldName, String replacedName) {

View on GitHub (pinned to db6a809a66)

Solutions

Delete the removed field from the input.
Provide a parserName for clearer errors and/or use a non-throwing deprecation handler if the field must be tolerated temporarily.

Defensive patterns

Strategy: validation

Validate before calling

// set parserName and 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().startsWith("deprecated fields not supported here") && e.getMessage().contains("deprecated entirely")) {
        // remove the field entirely and retry
    }
}

Prevention

Always provide parserName to get the more informative variant.
Remove fully-deprecated fields from input before strict parsing.
Maintain a per-version removed-field blocklist at the controller.

When it happens

Trigger: Unnamed strict parser rejecting a removed deprecated field. Encountered in test/internal parsers created without a name.

Common situations: Ad-hoc unnamed parsers enforcing strict deprecation. Shared utilities that did not set parserName.

Related errors

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