You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using .net and the Firely nuget. We have updated from the 0.96 version of the Firely Nuget package to the latest (5.4.0). As a result we've found, when reading a resource from a third party, that Firely removes all newlines from the end of the resource properties. This behaviour was not present in the old 0.96 version.
To Reproduce
Use the FhirClient to read a resource (e.g. by calling fhirClient.Read($"Appointment/{appointmentId}") where the appointment resource contains a Comment property with a newline at the end
Expected behavior
When reading a resource - e.g. by calling fhirClient.Read($"Appointment/{appointmentId}" we would expect the resource properties to contain the exact value as held in the raw JSON data. No trailing new lines should be removed.
Screenshots
The below screenshot is from Visual Studio where I have a break-point after the API call. It shows two orange circles. The top one shows the content of the Comment property in the Resource/POCO, which has no trailing new line. The second circle shows the raw json with the trailing new line.
Version used:
FHIR Version: R4
Version: 5.4.0
Additional context
The reason this is a problem for us....
In one particular implementation we read an appointment (by calling fhirClient.Read($"Appointment/{appointmentId}") and receive an Appointment resource which contains a Comment property with a newline at the end. I can see in the raw JSON response the newline is present, however the Appointment Resource/POCO given to us in code by Firely has the newline removed from the end of the Comment property.
This presents a problem for us with a particular integration when cancelling appointments. The integration specification states we should read the appointment, update it's Status to 'cancelled' and then send it back. The third party system will then validate our cancellation request, however they are rejecting our cancellation because it's not just the Status that has changed on the Appointment - The comment has changed as well - the trailing new line has been removed. Ideally the third party would not be so picky, however they are conforming to the specification. And to be fair we want the POCO to contain exactly what was present in the raw JSON anyway.
I did search the Firely github code and found this...
It sounds like it is trimming JSON text to be compatible with the xml serializer, so maybe that is the code that is the problem – and if so then possibly on purpose? If this is therefore by design and not a bug, can we have a configuration option to NOT remove these trailing new lines?
The text was updated successfully, but these errors were encountered:
This is fixed in the new serializers/deserializers! We're leaving the original serializers untouched, since the behaviour has been around for quite long (a lot has happened since 0.96 ;-)), so we're trusting on the new serializers (which are more speedy too) to solve this.
Many thanks for your quick reply.
How do I 'plug this in' / 'turn this on' for use with the FhirClient. e.g. calling FhirClient.Read($"Appointment/{appointmentId}")
I'm not explicitly serializing/deserializing the JSON myself with the serializers. I'm just using the FhirClient to call an endpoint. Do I need to set something on the FhirClientSettings to tell it to use the new deserializer so it keeps the newlines when deserializing the raw JSON into the POCO / Resource properties?
Describe the bug
We are using .net and the Firely nuget. We have updated from the 0.96 version of the Firely Nuget package to the latest (5.4.0). As a result we've found, when reading a resource from a third party, that Firely removes all newlines from the end of the resource properties. This behaviour was not present in the old 0.96 version.
To Reproduce
fhirClient.Read($"Appointment/{appointmentId}"
) where the appointment resource contains a Comment property with a newline at the endExpected behavior
When reading a resource - e.g. by calling
fhirClient.Read($"Appointment/{appointmentId}"
we would expect the resource properties to contain the exact value as held in the raw JSON data. No trailing new lines should be removed.Screenshots
The below screenshot is from Visual Studio where I have a break-point after the API call. It shows two orange circles. The top one shows the content of the Comment property in the Resource/POCO, which has no trailing new line. The second circle shows the raw json with the trailing new line.
Version used:
Additional context
The reason this is a problem for us....
In one particular implementation we read an appointment (by calling fhirClient.Read($"Appointment/{appointmentId}") and receive an Appointment resource which contains a Comment property with a newline at the end. I can see in the raw JSON response the newline is present, however the Appointment Resource/POCO given to us in code by Firely has the newline removed from the end of the Comment property.
This presents a problem for us with a particular integration when cancelling appointments. The integration specification states we should read the appointment, update it's Status to 'cancelled' and then send it back. The third party system will then validate our cancellation request, however they are rejecting our cancellation because it's not just the Status that has changed on the Appointment - The comment has changed as well - the trailing new line has been removed. Ideally the third party would not be so picky, however they are conforming to the specification. And to be fair we want the POCO to contain exactly what was present in the raw JSON anyway.
I did search the Firely github code and found this...
firely-net-sdk/src/Hl7.Fhir.Base/Serialization/FhirJsonNode.cs
Line 185 in 98d7fbe
It sounds like it is trimming JSON text to be compatible with the xml serializer, so maybe that is the code that is the problem – and if so then possibly on purpose? If this is therefore by design and not a bug, can we have a configuration option to NOT remove these trailing new lines?
The text was updated successfully, but these errors were encountered: