Issue with gatling 3.4.0. Match and Case inside HttpRequestBuilder don't work

Hi, I have problem with new version of Gatling 3.4.0.

gatling-sbt 3.2.1,

sbt 1.3.13.

My code looks like that:

In the new version of Gatling, I cannot use match and case. When I run test and execute this “post” method I don’t have any response from this request. Moreover, when I debug line 17 and 18 I have an empty string response.

In version 3.3.0 and 3.3.1 this code properly executed and I have a response body and current location. I don’t know if it’s a bug or maybe in the new version I should change scala syntax.
Moreover, when I run test without “match and case” in the new version, everything works fine.

Regards,
Daniel

Honestly, impossible to tell with so little information.

We recommend providing a Short, Self Contained, Correct (Compilable), Example (see http://sscce.org/) as explained in the group’s terms.
At the very least, please trim down your sample and provide logs.

I added a log from the simulation. I pasted a related log for this call. Sorry for the little information but I don’t know where I should look. It looks strange, why the same code works fine in the old version, and when I run a test with the new version I have a problem to execute this code and as I wrote previously I have empty responses for this “post” method.

ERROR io.gatling.http.engine.response.DefaultResponseProcessor - ResponseProcessor crashed while handling response 200 OK

simulation.log (20 KB)

Got it!
Since https://github.com/gatling/gatling/issues/3915, HTTP checks are sorted according to their “scope”.
In your case, HTTP status checks are applied BEFORE body checks, but you have conditional status checks that depend on data saved from a body check.

I have to say I’m pretty surprised by this way of doing things.
I would really expect the other way around: check the status, and if it’s 200, check the body.
Could you please elaborate?

Thanks for your explanation. I changed that. It was legacy code and honestly, I didn’t remember why I did like that. I guess it was related to our system but now it doesn’t matter. Thanks for your help.

Great!

I’ll mention this in the migration guide and will keep on monitoring if similar issues keep on being reported.
The new sort order looks correct to me, but maybe we’ll realize it might make sense to give lower precedence to conditional checks.
The key point of this change was that, as we only report the first failing check, it makes more sense to get reported a failing 404 status than a failing JsonPath check because the body is obviously wrong on 404.