What causes "Document contains the path but was expected not to." in json-path/JsonPath?

Inspect the JSON document at that path to confirm the field still exists.

json-path/JsonPath · error · AssertionError

Document contains the path <%s> but was expected not to.

Error message

Document contains the path <%s> but was expected not to.

What it means

assertNotDefined verifies that a JSON path does NOT exist in the document. It attempts to read the path; if the read succeeds (PathNotFoundException is NOT thrown), the path is defined and an AssertionError is thrown. This is an intentional negative-existence assertion failure.

Source

Thrown at json-path-assert/src/main/java/com/jayway/jsonassert/impl/JsonAsserterImpl.java:76

    }

    /**
     * {@inheritDoc}
     */
    public <T> JsonAsserter assertEquals(String path, T expected) {
        return assertThat(path, equalTo(expected));
    }

    /**
     * {@inheritDoc}
     */
    public JsonAsserter assertNotDefined(String path) {

        try {
            Configuration c = Configuration.defaultConfiguration();

            JsonPath.using(c).parse(jsonObject).read(path);
            throw new AssertionError(format("Document contains the path <%s> but was expected not to.", path));
        } catch (PathNotFoundException e) {
        }
        return this;
    }

    @Override
    public JsonAsserter assertNotDefined(String path, String message) {
        try {
            Configuration c = Configuration.defaultConfiguration();

            JsonPath.using(c).parse(jsonObject).read(path);

            throw new AssertionError(format("Document contains the path <%s> but was expected not to.", path));
        } catch (PathNotFoundException e) {
        }
        return this;
    }

View on GitHub (pinned to 62a4c9f0f6)

Solutions

Inspect the JSON document at that path to confirm the field still exists.
Remove the field at the source (fixture, API, serialization config) if it should be gone.
If presence is now legitimate, delete or invert the assertion.
Double-check path syntax — a too-broad path like '$..name' can unexpectedly resolve.

Example fix

// before
with(json).assertNotDefined("$.legacyId");
// after
if (JsonPath.read(json, "$.legacyId") != null) {
    json.remove("legacyId"); // or update fixture
}
with(json).assertNotDefined("$.legacyId");

Defensive patterns

Strategy: validation

Validate before calling

try { JsonPath.read(json, path); failOnce(path + " is defined"); } catch (PathNotFoundException expected) { /* ok */ }

Try / catch

try {
    with(json).assertNotDefined(path);
} catch (AssertionError e) {
    log.warn("Unexpectedly defined: {}", path);
    throw e;
}

Prevention

After removing a field, grep the serialization code/fixture for it.
Use precise paths rather than broad recursive-descent (..) ones.
Run this assertion in CI against freshly generated responses.

When it happens

Trigger: JsonAssert.with(json).assertNotDefined("$.removedField") when the field is still present in the document; also invoked by the two-arg overload with a message.

Common situations: Regression tests asserting a deprecated/removed field is gone from an API response, or that a filter matched nothing — failing because the field was re-added or the path actually resolves.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

AI-assisted analysis of json-path/JsonPath@62a4c9f0f6 (2026-09-11). Data as JSON: /api/errors/f7d8fe851d38041e. Report an issue: GitHub.