I asked about the failures in Quarkus' Tulip:

https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Upgrading.20Quarkus.203.2E5.2E0.20to.203.2E7.2E4.3A.20no.20default.20parser.20has.20been

It looks like this might be because RestAssured doesn't support JSON-B. rest-assured/rest-assured#1651

I tried to switch to Jackson in a local project, but failed. Any ideas, @vishal423?

Lately, I haven't got much chance to continue quarkus exploration, so, can't say for sure if there is an easy solution. BTW, did you try setting content type in the response to see if that works?

All tests pass with Quarkus 3.6.9 so this seems to be related to version 3.7+. Maybe we should just release a version with 3.6 and upgrade to 3.7 later?

FWIW, I think we should release with 3.6 now and figure out how to upgrade to 3.7 later.

I don't see a reason why it would preferable to wait for 3.7 for a release. It's not clear when the issue hindering the update will be resolved.

Another release can be made after the update.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@mraible 3.8 is out: https://quarkus.io/blog/quarkus-3-8-released/

I can try to do a release later tonight or tomorrow morning.

All tests pass with Quarkus 3.6.9 so this seems to be related to version 3.7+. Maybe we should just release a version with 3.6 and upgrade to 3.7 later?

I spent some time on this issue and it stems from the authentication failure while making a GET user request. Strangely, the code works with 3.6.x and that seems wrong to me.

If you replace the code

        var updatedUser = get("/api/admin/users/{login}", managedUserVM.login).then().extract().body().as(User.class);

with

        var updatedUser = given()
            .auth()
            .preemptive()
            .oauth2(adminToken)
            .accept(APPLICATION_JSON)
            .when()
            .get("/api/admin/users/{login}", managedUserVM.login)
            .then()
            .extract().body().as(User.class);

then, the test seems to work fine (change needs to be done across all GET User calls that don't pass the JWT token)

I see it as a security bug that seems undetected before 3.7.x release. I will hold release as I believe we must address this.