JSON decoding issues after upgrade to Spring Cloud 2023.0.2 #2158
Assignees
Comments
|
Using WebMVC the same error occured. I reverted back to 2023.0.1 until I know hot to fix that. |
Closed
|
Can you provide a minimal reproducer that shows the error in a test case? |
|
As it prevents me from upgrading, |
|
OK, more digging. The response is:
This is not readable, so here is it formatted: {
"id": "bfd1d723-0656-4b34-96a4-ce736c018eb3",
"version": 14,
"name": "Hydraulik Schneider Demo",
"logoUrl": "fd70beb2-c64e-4551-8607-afb7adaf1a3e",
"logoAssetId": null,
"homepageUrl": "http://hydraulik-schneider.de",
"publicContentDomain": "http://hydraulikschneider.public.localhost",
"billingAddress": {
"name": "Hydraulik Schneider AG",
"additionalNameRow": null,
"street": "Beispielstraße",
"houseIdentifier": "42z",
"zipCode": "54321",
"city": "Beispielhausen",
"state": null,
"country": "Deutschland"
},
"presets": {
"colors": {
"primary": "#00589C"
},
"general": {},
"blockDefaults": null,
"activeCss": null,
"draftCss": null,
"cssClassNames": null,
"imprint": null,
"dataProtectionOfficer": null
},
"auditMetaData": {
"createdBy": "demo",
"createdDate": "2024-05-28T18:15:21.255939Z",
"modifiedBy": "[email protected]",
"modificationDate": "2024-07-03T11:02:09.989323Z"
},
"_links": {
"self": {
"href": "http://localhost:9087/bfd1d723-0656-4b34-96a4-ce736c018eb3"
},
"fetchCustomCss": {
"href": "http://localhost:9087/bfd1d723-0656-4b34-96a4-ce736c018eb3/customcss{?draft}",
"templated": true
},
"fetchCustomCssNames": {
"href": "http://localhost:9087/bfd1d723-0656-4b34-96a4-ce736c018eb3/customcss/names"
},
"fetchViaContentDomain": {
"href": "http://localhost:9087/?contentDomain=http%3A%2F%2Fhydraulikschneider.public.localhost"
},
"updateTenant": {
"href": "http://localhost:9087/bfd1d723-0656-4b34-96a4-ce736c018eb3",
"type": "PUT"
}
}
}I can't see any problem here. And both RestClient and Webclient fail with the same exception. I am not providing my own objectmapper, as far as I can see to the context. And the problem is not present in 2023.0.1. The error is triggered in the Jackson2HalModule while doing |
|
@pcornelissen Is there something I could (easily) test on our side to provide more information? Sadly I had no time to dig deeper but it's blocking our update as well :-( |
|
Well, I have exhausted the time I can invest for now. I have reverted to 2023.0.1 and the problem is gone. As a workaround, you can try to fetch the result as string and use the objectmapper yourself, but I ran into the problem that the objectmapper was not configured for hateoas (although I used the builder) and this lead to the fact that the links of the entity were not parsed. But that may be a viable workaround with a proper object mapper. It seems the problem is purely on the clientside. i have compared the input that came over the wire and it looked the same no matter if the sending service was on 2023.0.2 or .1 If you find a solution, please report here. I get anxious when I am too far behind with updates ;-) |
|
I'm afraid that without a stack trace, some information about which Spring Cloud components are involved or anything that allows us to reproduce the issue, it's difficult to even remotely diagnose what the problem could be. Can anyone provide that information? |
|
Well, a stacktrace is easy: The only thing I have to change to trigger this is switch from 2023.0.1 to 2023.0.2 in the service that triggers this error. No other change is necessary, the "source service" can remain on 2023.0.1 or be at 2023.0.2 as well, it doesn't matter. |
|
What's weird is that you seem to be able to pinpoint the issue on the Spring Cloud update, but there's no Spring Cloud involved in the stacktrace. Can you elaborate what you mean with "source service"? On which side does the update cause an issue? Are you saying the system serving the response, alters the response as an effect of the upgrade so that the client breaks? Or is it the client that starts failing to read the response? |
|
Same issue here after the switch to 2023.0.2. We run integrations tests using TestRestTemplate.excahange(...). Parsing the response into proper Java object fails now: I debugged into the whole thing and the key is within and with the old version the config did not have |
|
Ah ok. Wenn I meant that this is communication between two microservices. The client is the one that throws the exception and the server spits out the same result, no matter which spring cloud version is in use. As far as I have seen it, the response from the server is identical with both versions. The client on the other hand fails when reading the second link in the result with the latest spring cloud. (I stepped through and this is what it looked like. The bytestreams make it a bit hard to follow the exact position in the document) |
|
Is there any chance you capture some of the payload and provide a minimal reproducer trying to statically read that? From what you describe the (reduced) content put into a file and an interaction with an |
|
The payload from my project is in the comments before |
|
Here is my payload: which will be deserialized into com.unboundid.scim2.common.messages.ErrorResponse which defines a specific deserializer (String => Integer) for the status field. And exactly that goes wrong. |
|
Spring Cloud 2023.0.3 fixed the issue for me |
Confirmed. It was fixed by spring cloud: spring-cloud/spring-cloud-function#1148 |
|
Confirmed from me as well, the problem is gone |
|
Looks like this can be closed then. Thanks everyone for their input! |
odrotbohm
added
resolution: works as designed
and removed
process: waiting for feedback
labels
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After upgrading to Spring Cloud 2023.0.2 a lot of tests in our services fail with
if they try to read the response body to a class that inherits from
RepresentationModel.As far as I can tell the
HypermediaWebTestClientConfigureris somehow involved. If I reomve it from ourWebTestClientthe response body can be read and the test fails due to class mismatches.Everything here is on the reactive stack. Do you have any suggestions what's going on here?
The text was updated successfully, but these errors were encountered: