Restore pre-8.0 behavior regarding array returned by jsonpath

[fubar-coder]

Problem to solve

I want to test whether - for example - jsonpath "$.emails[?(@.subject=='expected subject')].receivers" returns 2 receivers in the first occurrence of the array element containing expected subject` as subject.

This test has become impossible since 8.0, as there is now a "convenience" functionality that implicitly replaces an array with a single element with the single element itself, which breaks all scripts that rely on first.

Proposal

There are several solutions:

• Restore the 7.x behavior
• Restore the 7.x behavior when a option is passed to hurl
• Allow first to accept objects or scalar values

Additional context and resources

Currently, I have no workaround for my use case. The exists predicate doesn't support my use case.

My original assertion was:

jsonpath "$.emails[?(@.subject=='expected subject')].receivers" first count == 2

[jcamiel]

Hi @fubar-coder

In Hurl 8.0.0, we had to change how JSONPath results were computed to support more expressions so the choice on our side was to break every existing Hurl tests or to break some particular scripts. We choose the later, but the rule is "simpler". JSONPath queries always return an array of results. If the array is only one element, the array is replaced by this element, and only in this case.

For instance, given your data is:

{
  "emails": [
    {
      "id": "1",
      "subject": "expected subject",
      "receivers": [
        "1-a",
        "1-b"
      ]
    },
    {
      "id": "2",
      "subject": "foo",
      "receivers": [
        "2-a",
        "2-b"
      ]
    },
    {
      "id": "3",
      "subject": "bar",
      "receivers": [
        "3-a",
        "3-b"
      ]
    },
    {
      "id": "4",
      "subject": "expected subject",
      "receivers": [
        "4-a",
        "4-b",
        "4-c"
      ]
    }
  ]
}

The JSONPath will returns and array of 2 elements:

[
  [
    "1-a",
    "1-b"
  ],
  [
    "4-a",
    "4-b",
    "4-c"
  ]
]

So, in Hurl, the generic rules will apply, an array stays an array.

So your Hurl expression test will be

jsonpath "$.emails[?(@.subject=='expected subject')].receivers" first count == 2

But if you've only one element with "expected subject":

{
  "emails": [
    {
      "id": "1",
      "subject": "expected subject",
      "receivers": [
        "1-a",
        "1-b"
      ]
    },
    {
      "id": "2",
      "subject": "foo",
      "receivers": [
        "2-a",
        "2-b"
      ]
    },
    {
      "id": "3",
      "subject": "bar",
      "receivers": [
        "3-a",
        "3-b"
      ]
    }
  ]
}

The JSONPath will returns and array of 1 element:

[
  [
    "1-a",
    "1-b"
  ]
]

So, in Hurl, we apply the "coercion" rule, an array become an element .

So your Hurl expression test will be (without the first)

jsonpath "$.emails[?(@.subject=='expected subject')].receivers" count == 2

We've made this cohertion rule so every Hurl script that test "simple" expression" like

jsonpath "$emails[0].subject" == "expected subject"

Is still working. We didn't want to break every script and have found a middlegrounf for everybody.

TLDR: because in your data you have only one mail with subject "expected subject",, you can drop the first filter and it should work.

[fubar-coder]

@jcamiel Sorry, but that is the problem: It's not guaranteed to be a single result element. There may be more. I want the first in every case. BTW: It used to work pre-8.0, so everyone on 7.x will most likely have broken scripts. I don't mind updating my scripts, but I have a use case which isn't supported by the recent change anymore. Just to clarify my use case:

• find the first entry matching the given subject
  • regardless whether there might be one or more, but never zero
  • the found entry might not be the first one
• get the value of the "receivers"
• test whether receivers is an array with 2 elements

Might be related to #4993 , so I guess I'm not the only one bitten by the change. However, an option for hurl or an option for the jsonpath to disable the "cohertion" would be welcome, which is why this is an enhancement request, as the current behavior is not a bug, but a desired (though breaking) change.

[jcamiel]

Indeed, the structure of our JSONPath queries depends on the data returned.
If we expose an option --no-jsonpath-coercion that will have the effects of always returning arrays (the results would be exactly the result of https://jsonpath.com), the consequences will be some expressions to be rewritten like:

jsonpath "$emails[0].subject" == "expected subject"

MUST be rewritten to

jsonpath "$emails[0].subject" first == "expected subject"

Would it be OK?

[fubar-coder]

@jcamiel Yes, that would be exactly what I'd expect to do in the first place and would align with everything I get from JSON Path online testers.

[jcamiel]

@fabricereix @lepapareil possible names options (the Hurl default behavior will not be changed unless this option is set):

• --no-jsonpath-coercion
• --no-jsonpath-unwrap
• --jsonpath-keep-array
• --jsonpath-strict-result
• --jsonpath-preserve-result
• --jsonpath-no-unwrap

[fabricereix]

a few more

• --jsonpath-raw
• --jsonpath-native
• --jsonpath-always-list

It will also depend on the default. Changing the default with a --no- option might be clearer.

[fubar-coder]

The --no-jsonpath-coercion sounds good. A --jsonpath-coercion would only make sense to override a default behavior set by a configuration file or environment variable.