`count` filter report errors for valid `jsonpath` requests (as per RFC 9535) which used to work in `v7.*.*`

[linkdd]

What is the current bug behavior?

count filter report errors for valid jsonpath requests:

{"success":true,"users":[{"name":"guest","roles":null},{"name":"root","roles":["admin"]}]}


error: Filter error
  --> .../acl_users.hurl:17:50
   |
   | GET http://localhost:5080/api/v1/users
   | ...
17 | jsonpath "$.users[?(@.name == 'root')].roles[*]" count == 1
   |                                                  ^^^^^ invalid filter input type
   |                                                           actual:   string
   |                                                           expected: list, bytes or nodeset
   |

error: Filter error
  --> .../acl_users.hurl:19:51
   |
   | GET http://localhost:5080/api/v1/users
   | ...
19 | jsonpath "$.users[?(@.name == 'guest')].roles[*]" count == 0
   |                                                   ^^^^^ missing value to apply filter
   |

Steps to reproduce

GET http://localhost:5080/api/v1/users
Authorization: Bearer {{admin_token}}
HTTP 200
[Asserts]
jsonpath "$.success" == true
jsonpath "$.users" count == 2
jsonpath "$.users[*].name" contains "root"
jsonpath "$.users[*].name" contains "guest"
jsonpath "$.users[?(@.name == 'root')].roles[*]" count == 1
jsonpath "$..users[?(@.name == 'root')].roles[*]" contains "admin"
jsonpath "$.users[?(@.name == 'guest')].roles[*]" count == 0

Have the endpoint return the following JSON:

{"success":true,"users":[{"name":"guest","roles":null},{"name":"root","roles":["admin"]}]}

What is the expected correct behavior?

Before 8.0.0, it used to work. Using the https://jsonpath.com playground, I can assert that both queries do return a list as per the RFC 9535:

• when roles is not null: playground link
• when roles is null: playground link

Execution context

• Hurl Version (hurl --version):

hurl 8.0.0 (unknown) libcurl/8.19.0-DEV OpenSSL/3.5.3 zlib/1.3.1
Features (libcurl):  alt-svc AsynchDNS HSTS IPv6 libz SSL UnixSockets
Features (built-in): brotli

Possible fixes

The new JSONPath implementation was introduced by #4270, maybe it's an upstream bug?

[jcamiel]

Hi @linkdd

Unfortunately the 8.0.0 comes with breaking changes (more information why we've done this here => http://hurl.dev/blog/2026/04/27/announcing-hurl-8.0.0.html#brand-new-jsonpath-rfc-9535-support). In particular, in order to minimise the breaking changes with all the existing Hurl files and also be coherent with other Hurl queries, we have make some changes to how results are processed:

• empty array in jsonpath.com → None value in Hurl 8.0.0
  jsonpath "$.store.book[5].title" not exists
• single-element array in jsonpath.com → the element itself in Hurl 8.0.0
  jsonpath "$.store.book[1].title" == "Sword of Honour"
• multiple elements in jsonpath.com → the full array of elements in Hurl 8.0.0
  jsonpath "$.store.book[0,2]" count == 2

In your case the query jsonpath "$.users[?(@.name == 'root')].roles[*]" count == 1 is OK in Hurl 7.0.0 but it's returing only one element in Hurl 8.0.0 (not a list of one element any more):

Before:

jsonpath "$.users[?(@.name == 'root')].roles[*]" count == 1
jsonpath "$..users[?(@.name == 'root')].roles[*]" contains "admin"
jsonpath "$.users[?(@.name == 'guest')].roles[*]" count == 0

After:

jsonpath "$.users[?(@.name == 'root')].roles[*]" exists
jsonpath "$..users[?(@.name == 'root')].roles[*]" == "admin"
jsonpath "$.users[?(@.name == 'guest')].roles[*]" not exists

[linkdd]

So, how do I assert that an endpoint returns :

• an empty array and not null
• an array with 1 element, not 2, not 0

An API wrongly returning null instead of an empty array would pass the test not exists. Same for an API wrongly returning a string instead of an array of 1 string, it would pass the test exists, and an API returning an array with more than 1 string would also pass the test exists.

[fabricereix]

Hi @linkdd
If I retake your JSON response with an additional user who has an empty array value for the role

{
    "success": true,
    "users": [
        {
            "name": "root",
            "roles": [ "admin" ]
        },
        {
            "name": "guest",
            "roles": null
        },
        {
            "name": "bob",
            "roles": []
        }
    ]
}

The JSONpath expressions can be simplified without using the [*] part.

jsonpath "$.users[?(@.name == 'root')].roles" count == 1
jsonpath "$.users[?(@.name == 'root')].roles" nth 0 == "admin"
jsonpath "$.users[?(@.name == 'guest')].roles" == null
jsonpath "$.users[?(@.name == 'bob')].roles" count == 0  

[verigak]

I was also affected by this change. In my case I was capturing the count:

[Captures]
available_slots: jsonpath "$.slots[?(@.status == 'available')]" count

Then generating different tests using asserts on the variable, e.g.:

[Asserts]
variable "available_slots" == 3

This pattern no longer works since the capture fails for counts of 0 and 1. I was able to workaround this by removing the Capture and using different asserts with not exists, exists or count == N depending the expected count, but it is more tedious.

[Chahahou]

This pattern no longer works since the capture fails for counts of 0 and 1. I was able to workaround this by removing the Capture and using different asserts with not exists, exists or count == N depending the expected count, but it is more tedious.

Since we are also affected, and we have the same kind of scenario with capturing the count, can you elaborate on your workaround? Did you find a way to handle a dynamic count in one single call or did you change to have several different calls with "static" counts?

In our case we rely on a dynamic count with something like:

[Captures]
nbItems: header "count" toInt
[Asserts]
jsonpath "$[?(@.field == 'xxxx')]" count == {{nbItems}}

[jcamiel]

Hi @Chahahou @verigak @linkdd

Instead of using the count Hurl filter, you maybe use the JSONPath count function (new function in RFC 9535).
For instance, given this JSON file:

[
  {
    "field":"foo"
  },
  {
    "field": "bar"
  },
  {
    "field": "foo"
  },
  {
    "field": "baz"
  },
  {
    "field": "foo"
  },
  {
    "field": "foo"
  }
]

If you want to insure a given number of field with a "foo" value, you can use:

GET http://localhost:8000/data.json
HTTP 200
[Captures]
nbItems: header "count" toInt
[Asserts]
jsonpath "$[?count($[?@.field == 'foo']) == {{nbItems}}]" exists

The assert is successful when there are exactly nbItems entries with field value equals to 'foo'

[Chahahou]

@jcamiel Thanks, it is working with count 1 or higher, but not when 0

   | jsonpath "$[?count($[?@.field == 'xxxx']) == 0]" exists
   |   actual:   none
   |   expected: something

[jcamiel]

@linkdd @verigak @Chahahou @fubar-coder

Even if we're not receiving a lot of feedbacks on the JSONPath changes in Hurl 8.0.0, we still don't like having some users bothered by these changes.

Would it be better if we do these changes in the next Hurl version:

• keeps the actual (new) JSONPath algo
• introduces an opt-in option --no-jsonpath-cohertion that would make every JSONPath query always returns an array (even if the results is an array of one element). The Hurl query result will be exactly the results in https://jsonpath.com, always returning an array.
• to make this option default, one can set an env var HURL_NO_JSONPATH_COHERTION or use the Hurl config file that will ship with Hurl 8.1.0

One consequence of activating this option would be that "simple" JSONPath queries like $.user[0].name would always return an array. So an Hurl file like this:

GET https://api.com
HTTP 200
[Asserts]
jsonpath "$.user[0].name" == "foo"

Must be changed with --no-jsonpath-cohertion to:

GET https://api.com
HTTP 200
[Asserts]
jsonpath "$.user[0].name" first == "foo"

Do you have any thought on this proposal?

Thanks!

[verigak]

Thanks for the response, in my case it would help if I could disable it only for a few specific requests in their [Options] section. I wouldn't want to disable it globally with a CLI arg or env variable, because I do appreciate the convenience in most other cases.

[jcamiel]

@verigak yes we could support it by request (unless implementation problem but I dont see one for the moment)

[fubar-coder]

@jcamiel I'd be fine with that solution, too. Having the option would be great.

EDIT: TBH, the cohertion does make things simpler most of the time, I can definitely see that.