BUG: AllOf sequence order is not preserved on parsing about libopenapi HOT 11 CLOSED

Hi, I'm offline for a couple of days during the holidays (I've not had any downtime this year), so, I haven't been able to look into this yet. I'm unsure why the ordering is different, but I can understand it being an issue.

I'll be back online in a couple of days and I can investigate this a little more. A fix should be nonbreaking.

from libopenapi.

I have provided an alternate PR that retains the async nature of the resolving while solving the original order issue here #66

from libopenapi.

#59 fails

from libopenapi.

@daveshanley Hi Dave. I am ready to work on the fix for this issue (it's kind of blocking for us). I'd like to have your opinion first on that.

from libopenapi.

I have suggested a fix. Please review when you have time.
It fixes all arrays processing, not only AllOf

from libopenapi.

I've added some comments. Generally, it looks OK, but I want to ensure we're not slowing things down for large specs, I don't think it will, but I want to make sure. So some A/B benchmark testing to verify it's not slowing things down (even though I'm pretty sure it won't)

from libopenapi.

Will try to comeup with some benchmarks.
But i think you forgot to submit your comments. I do not see them

from libopenapi.

Apologies forgot to press submit, I got distracted with some code.

from libopenapi.

Have just ran into this issue as well, as order of allOf determines how the resulting object is resolved and if the order is incorrect then things may not be overridden correctly (if two allOf schemas specify the same fields for example the first one in the list gets overriden by the second one in the list for example)

from libopenapi.

Once we're confident about the change @bitomaxsp has put in place in #59, this should be resolved.

from libopenapi.

Now that #66 has been merged in (thank you for your contribution @TristanSpeakEasy). We should be able to close the book on this issue.

from libopenapi.