Malformed Faults fail in non-informative ways

[hartsock]

Malformed Faults fail in non-informative ways. Example: LicenseUsageFaults will emit the following SOAP envelope. This envelope will not properly map onto the ServerFaultCode data type inside pyVmomi. The result is that the message will not map onto the appropriate fault type.

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <soapenv:Fault>
      <faultcode>ServerFaultCode</faultcode>
      <faultstring/>
      <detail>
        <LicenseUsageFaultFault xsi:type="LicenseUsageFault">
           <reason>dataTampered</reason></LicenseUsageFaultFault>
      </detail>
    </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

[hartsock]

At present, I have not been able to determine if the library can successfully deserialize and then marshal a fault object. The XML parsers seem capable of handling the payload from initial testing.

[hartsock]

After two days in the debugger I've figured out that the SoapAdapter.py matches the detail tag's first child tag name against the WSDL and then maps that to a data type. In this case the data type vmodl.fault.LicenseUsageFaultFault would make sense (FaultFault? really guys?) but the type is not present in the WSDL. That causes a key error when attempting to perform dynamic type look up. Trace is below...

Traceback (most recent call last):
  File "/Applications/PyCharm.app/helpers/pydev/pydevd.py", line 1539, in
<module>
    debugger.run(setup['file'], None, None)
  File "/Applications/PyCharm.app/helpers/pydev/pydevd.py", line 1150, in run
    pydev_imports.execfile(file, globals, locals) #execute the script
  File "/Users/hartsocks/PycharmProjects/pyvmomi/sample/poweronvm.py", line
153, in <module>
    main()
  File "/Users/hartsocks/PycharmProjects/pyvmomi/sample/poweronvm.py", line
144, in main
    vm.TerminateVM()
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/VmomiSupport.py", line
553, in <lambda>
    self.f(*(self.args + (obj,) + args), **kwargs)
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/VmomiSupport.py", line
362, in _InvokeMethod
    return self._stub.InvokeMethod(self, info, args)
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/SoapAdapter.py", line
1226, in InvokeMethod
    obj = SoapResponseDeserializer(outerStub).Deserialize(fd, info.result)
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/SoapAdapter.py", line
747, in Deserialize
    self.parser.ParseFile(response)
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/SoapAdapter.py", line
569, in StartElementHandler
    objType = self.LookupWsdlType(ns, name[:-5])
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/SoapAdapter.py", line
559, in LookupWsdlType
    return GuessWsdlType(name)
  File "/Users/hartsocks/PycharmProjects/pyvmomi/pyVmomi/VmomiSupport.py", line
1017, in GuessWsdlType
    raise KeyError(name)
KeyError: u'LicenseUsageFault'

To be able to support arbitrary Fault tags we need to put in a trap for Faults that will allow the type resolution logic to escape to a known-good data type if you can't match the data type based on the detail tag's first child.

[hartsock]

The proposed resolution to this problem is to include the malformed XML document inside the Exception. This has the benefit of allowing a developer to see exactly what killed their client and to include this information in incident reports. We can then build fixtures to simulate the failure and resolve this class of problem much more quickly.

This does impact performance and stack trace message size.