-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binary resource returned from Update will throw a Null reference error trying to SerializeToXmlString #2786
Comments
The philosophical question is: "is a renamed property still the same property".
Another point to consider: when we add support for having unknown properties in resources (added to a dictionary, but not available via a code-generated property) in preparation of R6 ("allow unknown elements"), having properties that do not exist in that version's metadata will become more common. No answers here, just a braindump of stuff to consider. |
Decided that this for now is one property with two names: Add:
On The problem that remains is having to fix Let's try and see what happens. |
Describe the bug
When serializing a Binary resource to XML a Null reference is thrown.
This is due to the children() function returning all the children without considering the version of fhir being processed.
Data
andContent
hold the same data, but are apprpriate in different versions, and the ReadBinaryFataFromMessage in the HttpContentParsers sets both.firely-net-sdk/src/Hl7.Fhir.Base/Rest/HttpContentParsers.cs
Line 203 in 963660e
Hence when hit in the PocoElementNode constructor the element definition for one of them isn't found and crashes.
Note: Create does not do this... as it doesn't detect that the resource type was for a Binary!
(so create is done using the resource format rather than a binary stream)
To Reproduce
Steps to reproduce the behavior:
Use this unit test to check that the serialization doesn't throw the issue, but would be preferable if the update functionality doesn't set both fields
Better to udpate
TestCreatingBinaryResourceHttpClient
to also check the fields are appropriateExpected behavior
Unit test should pass, and XML is created correctly.
Version used:
Additional context
The only workaround is to request the resource response format in the client settings.
clientFhir.Settings.BinaryReceivePreference = BinaryTransferBehaviour.UseResource;
The text was updated successfully, but these errors were encountered: