Possible fix for: #658

[acidjunk]

As requested in #658 : a failing test.

[codecov[bot]]

Codecov Report

Merging #714 into master will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #714   +/-   ##
=======================================
  Coverage   89.02%   89.02%           
=======================================
  Files          61       61           
  Lines        4646     4646           
  Branches      818      818           
=======================================
  Hits         4136     4136           
  Misses        332      332           
  Partials      178      178

[acidjunk]

@mvantellingen Now the same test fail that are also already failing in master. The tests contain one test that succeeds test_find_customer() and one test that fails test_find_product().

[mvantellingen]

Hi, thanks for this. Is it possible to reduce the test code so we don't need to add multiple xsd files?

[acidjunk]

Yes that should be possible: but I wonder if that 's not the root cause of this issue: IMHO the bug itself was introduced in a commit that tries to solve another (regression)bug.

I can confirm that the current behaviour is an regression though: version 0.27, 1.0, 1.1 and 1.2 work ok (strict mode enabled from v 1.1)

from version 1.3 and up it returns parse errors. Luckily this narrows it down a lot as there is only 2 days between version 1.2 and 1.3 :-)

AFAIK the regression is introduced in commit: 349c27c The last OK commit: bdb2a14

As I don't know enough about XSD/nesting/complex types I'm having an hard time to actual understand what problem/regression 1.2 had that was supposedly fixed in 1.3? Can I trust the facked XSD? And the way I see it, the bug will be somewhere in XSD's that inherit more then once from a complex type. Not for all of these constructs: as in my example some of the call's work ok: so I assume it also is related to the order of XSD object definitions.

For now we use my fork with a fix: I'm willing to improve the test in my free time (or to add a new one) when I get a bit clarity of:

• the actual regression that 1.3 fixes
• chances that this fix will result into a release (so I can remove the fork from our requirements)

[hmvp]

@mvantellingen I rebased the original fix and updated the testcase to be a lot smaller. However the original fix (as found in https://github.com/acidjunk/python-zeep/blob/original_fix/src/zeep/xsd/types/complex.py) does not work anymore in 4.0.0

Would you be so kind to check why the second assert of the tests fail and see if you can fix that?

[hmvp]

@mvantellingen I rebased the original fix and updated the testcase to be a lot smaller. However the original fix (as found in https://github.com/acidjunk/python-zeep/blob/original_fix/src/zeep/xsd/types/complex.py) does not work anymore in 4.0.0

Would you be so kind to check why the second assert of the tests fail and see if you can fix that?

Hmm I might have simplfied to much due to xsd_ignore_sequence_order=False let me check my testcase again

[hmvp]

Had to slightly tweak the test (I'm sorry for the huge wsdl, but reducing somehow removed the error)

Also added a fix for some existing issues in the master branch feel free to ignore if not wanted

[acidjunk]

Let me know if there is anything that could be done to speed things up. The bug and a wrong test was introduced after a very short described issue on which the author of the issue never replied); so the process to get this accepted feels a bit ironic. If there is a way to sponsor/donate that has a positive effect on the speed : that would be very nice.