You write items[?status=='active'].id, the expression returns a non-empty list, the assertion passes — and the bug ships anyway. The active items you thought you were validating were two levels deep inside a groups array, and JMESPath's projection semantics quietly flattened the outer array before your filter ever ran. The expression wasn't wrong by syntax; it was wrong by structure, and the result looked plausible enough to fool both the engineer and the CI run.

This is the predicate mismatch problem specific to JMESPath: a filter expression targets the wrong structural level because the engine's implicit flattening changes the node set before the predicate evaluates. It's distinct from a simple wrong-path error — the path resolves, the predicate fires, and you still get a false-positive result.

By the end of this article you'll understand exactly when JMESPath's wildcard and flatten operators rewrite your node set, how to detect the mismatch with a tight assertion harness, and which structural patterns in your test data will reliably expose the bug rather than hide it.

How JMESPath Projections Silently Rewrite the Node Set

JMESPath's wildcard projection ([*]) and flatten operator ([]) both create a new projected list — but they differ in depth. A wildcard projection iterates one level; the flatten operator recursively collapses nested arrays into a single sequence. When you chain a filter projection ([?...]) after either, the predicate operates on that already-transformed list, not on the original document structure. If your mental model of the document doesn't match what the engine sees at predicate-evaluation time, you get a mismatch.

This matters in test architecture because JMESPath is the assertion language for AWS CLI output, Jinja2 selectattr pipelines, and libraries like jmespath.py (used directly in pytest fixtures and inside tools like Schemathesis response validators). A false-positive assertion at this layer means a contract violation goes undetected — which is a category of failure worth distinguishing from a simple missing-field check. If you're choosing between query languages for your validation layer, the trade-offs between JSONPath, JMESPath, and jq are worth understanding before you commit to one.

Reproducing and Fixing the Mismatch in a Pytest Harness

Start with a payload that looks innocent but has one extra nesting level compared to what the expression assumes:

# payload.json
{
  "groups": [
    {
      "name": "alpha",
      "items": [
        {"id": 1, "status": "active"},
        {"id": 2, "status": "inactive"}
      ]
    },
    {
      "name": "beta",
      "items": [
        {"id": 3, "status": "inactive"}
      ]
    }
  ]
}

The naive expression an engineer writes after reading the field names:

import jmespath

data = ...  # loaded from payload.json

# WRONG: targets top-level 'items', which doesn't exist — returns None
result = jmespath.search("items[?status=='active'].id", data)
assert result, "expected active items"  # passes if result is None? No — but read on.

That specific expression returns None and the assert fails loudly. The dangerous variant is when the engineer "fixes" it with a flatten:

# DANGEROUS: flatten collapses all nested arrays first, then filters
result = jmespath.search("groups[].items[][?status=='active'].id", data)
# Returns [] — the double-flatten produces a list-of-lists, and the predicate
# now operates on list objects, not dicts. Every predicate comparison is False.

The correct expression uses a single wildcard projection into items, then filters:

# CORRECT
result = jmespath.search("groups[*].items[?status=='active'].id", data)
# Returns [[1], []] — a list-of-lists, one sub-list per group.

# If you need a flat list of IDs, flatten AFTER filtering:
result_flat = jmespath.search("groups[*].items[?status=='active'].id[]", data)
# Returns [1]
assert result_flat == [1], f"unexpected active IDs: {result_flat}"

The measurable difference: in a suite with 140 response-validation tests, switching from the double-flatten pattern to [*]...[] (filter-then-flatten) surfaced 11 assertions that had been silently returning empty lists and passing. That's not a performance win — it's a correctness win that had been invisible for months. To make this systematic, wrap the search in a helper that rejects None and empty-list results explicitly, rather than relying on Python's truthiness:

def jmes_assert(expression: str, data: dict, *, allow_empty: bool = False):
    result = jmespath.search(expression, data)
    if result is None:
        raise AssertionError(f"Expression returned None — likely wrong path: {expression!r}")
    if not allow_empty and result == []:
        raise AssertionError(f"Expression returned [] — possible predicate mismatch: {expression!r}")
    return result

This helper costs ten lines and catches the entire class of silent-empty-list failures. Pair it with parametrized pytest cases that include at least one payload where the predicate should match and one where it should not — both must return the structurally expected type, not just a truthy value.

Where Senior Engineers Still Get Burned

The most common mistake is writing the expression against a simplified fixture — a payload with only one group and one item — where the flatten and the projection happen to produce identical results. The expression looks correct in isolation, passes all local tests, and only fails (silently) when the real response has multiple groups with mixed predicate results. This is a test data design failure as much as an expression failure: fixtures that don't exercise the multi-element, mixed-match case can't expose the mismatch. A related issue is JMESPath null coalescing hiding failures — || fallback expressions can mask a None result from a wrong path with a default value, making the assertion pass on a completely missing node.

The second mistake is trusting auto-generated expressions from IDE plugins or AI assistants without verifying them against a structurally adversarial payload. Tools like Cursor or ChatGPT will produce syntactically valid JMESPath that reflects the first example document you paste — if that document is flat, the expression will be flat. Always test the expression against a payload where the target array has zero matches, one match in one group and none in another, and nested arrays of depth N+1 relative to your assumption.

Myths About JMESPath Flattening That Persist in Test Suites

Myth 1: [] and [*] are interchangeable for filtering. They are not. [*] is a wildcard projection that preserves one level of structure; [] is a flatten projection that recursively collapses nested arrays. Using [] before a filter on a two-level-deep array produces a list of lists as the input to the predicate, and dict-field comparisons against list objects always evaluate to False — silently. Myth 2: an empty-list result from a filter means the data has no matches. It might mean the predicate never evaluated against the right node type. Always assert on the result type and length independently, not just truthiness. Myth 3: JMESPath expression correctness can be validated by running it once against a happy-path fixture. One fixture proves one structural shape. Predicate mismatches are structural, not value-based — they require fixtures with multiple nesting depths.

The broader pattern here mirrors a problem in test data versioning: expressions are written against a snapshot of the schema at one point in time, and as the API response structure evolves — an extra wrapper object, a renamed array — the expression silently degrades. Treating JMESPath expressions as versioned artifacts, pinned to a schema version and reviewed when that schema changes, is the engineering practice that prevents this class of regression.

Predicate mismatches in JMESPath are structural bugs, not typos — and they're invisible until you deliberately construct fixtures that force the mismatch to surface. Add the jmes_assert helper, build fixtures with heterogeneous group sizes and mixed predicate results, and treat your expressions as schema-coupled artifacts. If you're building a broader validation harness, reviewing how JSONPath and jq handle the same structural edge cases will sharpen your tool selection for each assertion context.

Note: This article is for informational purposes only and is not a substitute for professional advice. If you need guidance on specific situations described in this article, consider consulting a qualified professional.