FhirClient throws wrong exception when server returns an HTTP error and non-FHIR body

[michelemottini]

If the remote server respond to a request with an HTTP error and a JSON or XML body that is not valid FHIR (that can happen when connecting by mistake to non-FHIR end points or when the error is generated by the server before hitting the actual FHIR code - like an authorization error) the resulting exception is ArgumentException instead of FhirOperationException, and the returned HTTP status code is lost.

Test:

        [TestMethod, TestCategory("FhirClient"), TestCategory("IntegrationTest")]
        public void UnauthorizedSearch()
        {
            var client = new FhirClient("http://fhir.careevolution.com/master.adapter1.webclient/api/fhir");
            var fhirOperationException = Assert.ThrowsException<FhirOperationException>( () => client.Search<Patient>(new[] { "family=Demosky" } ) );
            Assert.Equals(HttpStatusCode.Unauthorized, fhirOperationException.Status);
        }

The problem appear to be at https://github.com/FirelyTeam/fhir-net-api/blob/develop-stu3/src/Hl7.Fhir.ElementModel/TypedElementOnSourceNode.cs#L42: it should throw a FormatException (?)

[ewoutkramer]

Hi Michele, this is caused by the new parser framework, which threw the wrong exception when illegal FHIR was encountered. This was fixed in PR #906, which was published in release 1.2. At the time of the PR, this file was called TypedElementNode.cs, and has since been renamed to `TypedElementOnSourceNode.cs.

I can now see that this fix was applied to R4, but is not present in the STU3 version. I'll chase down what happened there.

[ewoutkramer]

Ah, I had noticed I had lost this and tried to correct it in ac6d6fa. I was not careful enough :-(

[ewoutkramer]

Fixed by #1022

[michelemottini]

Thanks Ewout - sorry to be a pest but it appears that DSTU2 needs it as well (that's the develop branch isn't it?)

[ewoutkramer]

Ah, yes - we have ceased active development of DSTU2, but if you need me to selectively apply this patch, I will do so.

[michelemottini]

Ah OK - no thanks, I am good, I just used the latest ElementModel package in our own fork of Core and that solves the problem for us