Exception when deserializing the result message after updating SoapCore

[cosmo0]

We have an app that was working with SoapCore 1.2.0, and is breaking with version 1.2.1.11. I have rolled back and it works with 1.2.0.1 but it breaks as soon as 1.2.1.0.

One of our middleware is crashing during the call to the "next" with the following error:

Type 'System.Xml.XmlAttribute' is an invalid collection type since it does not have a valid Add method with parameter of type 'System.Object'.

And the stacktrace:

   at System.Runtime.Serialization.DataContracts.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String message, Type type)
   at System.Runtime.Serialization.DataContracts.CollectionDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
   at System.Runtime.Serialization.DataContracts.CollectionDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
   at System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
   at System.Runtime.Serialization.DataContracts.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
   at System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
   at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectContentHandleExceptions(XmlWriterDelegator writer, Object graph)
   at System.ServiceModel.Channels.XmlObjectSerializerHeader.OnWriteHeaderContents(XmlDictionaryWriter writer, MessageVersion messageVersion)
   at System.ServiceModel.Channels.MessageHeader.WriteHeaderContents(XmlDictionaryWriter writer, MessageVersion messageVersion)
   at System.ServiceModel.Channels.MessageHeaders.WriteHeaderContents(Int32 headerIndex, XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.MessageHeaders.WriteHeader(Int32 headerIndex, XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.Message.WriteMessagePreamble(XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.Message.OnWriteMessage(XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.Message.WriteMessage(XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.Message.WriteMessage(XmlWriter writer)
   at SoapCore.MessageEncoder.SoapMessageEncoder.<WriteMessageAsync>d__41.MoveNext()
   at SoapCore.SoapEndpointMiddleware`1.<ProcessOperation>d__15.MoveNext()
   at SoapCore.SoapEndpointMiddleware`1.<Invoke>d__10.MoveNext()
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<<Invoke>g__AwaitRequestTask|7_0>d.MoveNext()
   at MyMiddleware.<Invoke>d__4.MoveNext() in MyMiddleware.cs

The middleware in question looks like (very simplified):

public partial class MyMiddleware
{
    private readonly RequestDelegate _next;

    public MyMiddleware(RequestDelegate next)
    {
        _next = next;
    }
    
    public async Task Invoke(HttpContext context) {
        // snip: do some stuff

        await _next(context); // this is the line crashing

        // snip: do some other stuff
    }
}

I can't really give you the response object, it's in a generated file that is 87175 lines long and the object is supposed to be composed of objects... Let me know how I can pinpoint the offending object or property, as I don't see anything in the exception that would help me figure it out.

Note that our request handler works fine and processes the request; the crash happens during serialization of the response.

Comparing the last working version with the newest non-working I don't find any change in SoapMessageEncoder.WriteMessageAsync so I'm not sure what's going on.

[andersjonsson]

There shouldn't be any changes to the response pipeline in that release, so that seems very weird.

I think the easiest way to narrow things down would be to create a unit test with a copy of your response object and then remove stuff from it until it works.

The error seems to imply that there are properties of type XmlAttribute[], List<XmlAttribute>, XmlAttributeCollection, or any other type of enumerable of XmlAttribute. But if that was the case, it shouldn't work with 1.2.0.1 either.

[cosmo0]

Thanks! We will try to find the exact culprit and get back to you.

I tried to add the project directly and debug it but I got lost and gave up 😅

[cosmo0]

We found out the source of the issue.

We are receiving a message with a MessageHeader element, and we re-use this element in the response.

This is the property that triggers the issue (if we remove it everything works again), with the value right before it crashes:

This is the request we receive (note the duplicated xmlns and xmlns:h):

And the response that is failing to deserialize (left with 1.2.1, right with the object manually modified to make the deserialization work):

In case it's not enough information, we're trying to create a minimal reproductible example, but it might take some time.

[andersjonsson]

Interesting... If you could create a small example, it'd be great! That would make debugging much easier.
If not, please try to get the parsed request message with version 1.2.0.1 and 1.2.1.0, so that we can compare them.

I have a hunch that 1.2.0.1 might remove one of the duplicate namespaces

[cosmo0]

My extremely talented colleague managed to create the MRE :)

SoapCore-Issue-1161.zip

Open the solution, run the project, open the http file with Visual Studio, click "send request" on the second query.

[andersjonsson]

Great that you found a way to reproduce the error

I can't really wrap my head around why it doesn't work anymore. Would it be possible for you to submit a PR with the repro-code in a unit test? Once there is a failing unit test, it will be possible to debug the code and get more info

[cosmo0]

@andersjonsson the PR is created #1168

As I mentioned in the description, the unit tests I created did trigger exceptions, but not the same one. I suspect I simply misconfigured the unit tests.

I added another project that you can run separately and that allows you to debug the library. Hope it helps!