Handling optional JSON null value

Gatling (Open-Source)
1

Hi Stephane et team,

One of response bodies in my load test can include JSON null value. The value can be seen as following when I have logback trace enabled:

`

body=
{“id”:1,“token”:null,“time”:12345}

`

The token in this case can either be null or include some text value. I have following check to store its text value when it is available:

`
.check(jsonPath("""$.token""").find.optional.saveAs(“token”))

`

This check has always worked for me with Gatling 2.X versions. Using Gatling 3.0.1 (latest + missing logback jars), I encountered following Gatling error/failure:

`
22:31:04.693 [ERROR] i.g.c.a.b.SessionHookBuilder$$anon$1 - ‘hook-128’ crashed with ‘j.l.ClassCastException: Value is null’, forwarding to the next one

`

My understanding is 2 new validations “isNull” and “notNull” are introduced in Gatling 3.0 (https://gatling.io/docs/current/http/http_check/#validating). However, I need the “optional” to handle both cases.

Thank you!

Vu

2

I’d like to add my experiences with the check below:

`
.check(jsonPath("""$.token""").find.optional.saveAs(“token”))

`

  • Gatling 2.2.0: the check does not store “token” in the session when $.token is null
  • Gatling 2.3.1: the check stores “token” in the session with null value when $.token is null
  • Gatling 3.0.1: the check fails with ClassCastException when $.token is null

Stephane, I think Gatling 2.2.0 has the most desired result in this case.

Thank you for your help.

Vu

3
  • Gatling 3.0.1: the check fails with ClassCastException when $.token is null

Are you really sure you get the CCE in the check. I suspect you actually get it when try to use the stored value.

The change was discussed in the bug tracker and was about telling the difference between:
{“id”:1,“token”:null,“time”:12345} <= value is null
and
{“id”:1, “time”:12345} <= key is undefined

“optional” won’t do any good in your case as “token” is defined and the check is extracting null.

4

I stand corrected. Your suspicion is spot-on, Stephane.

After additional debugging, I found that Gatling 2.3.1 and Gatling 3.0.1 both store “token” in the session when its key is defined and its value is null.

The difference in behavior is when I use the session(“token”) afterward as follows:

`
val newToken = Option(session(“token”).as[String]).getOrElse(“default”)

`

  • With Gatling 2.3.1, newToken is successfully assigned the “default” value.
  • With Gatling 3.0.1, ClassCastException is caught. This CCE can be avoided when I use matching with Validation (session(“token”).validate[String]).

Looks like Gatling 3.0.1 behavior in this case is expected.

Thank you again for your help.

Vu