It does no good to anyone, anywhere and is creating race conditions when using the stack in a multi-tenant fashion.
Signed-off-by: quobix <dave@quobix.com>
I have seen this issue appear online a few times, the CPU locks at 100% when throwing a bad reference.
This happened because the local ‘lock’ used by the rolodex file loader, was not releasing correctly when a
lookup occurred, that could not be found via a rolodex file lookup.
https://github.com/daveshanley/vacuum/issues/393
Signed-off-by: quobix <dave@quobix.com>
Signed-off-by: quobix <dave@quobix.com>
Move original ref resolving to end of resolving run
this prevents mid-recursion shifting of nodes.
Signed-off-by: quobix <dave@quobix.com>
speakeasy have some crazy recursive tests. It highlighted an issue with nested resolving intriduced in 0.13.7 of libopenapi to resolve issue #195
This in fact created another bug that only shows up with deeply nested refs, the problem is that the resolver was stitching together references, whilst still burrowing, which means it lots it’s place when jumping around everywhere.
Signed-off-by: quobix <dave@quobix.com>
stopped rolodex looking up root file, looking in components schemas for a reference also. Dropped stripe circular refs down by one. seems to be catching the duplicate now.
Signed-off-by: quobix <dave@quobix.com>
This builds on the last patch, by also catching the issue in the resolver and then allowing it to bubble up to applications.
no new fixes, no new featuers, just better integration so vacuum can report the issues.
Signed-off-by: quobix <dave@quobix.com>
If the number of relatives exceeds 500 deep when resolving, libopenapi will now log a warning and escape that path from continuing. There is no reason on earth for a depth this large. It most likely indicates a circular reference that was ignored and then resolved.
Signed-off-by: quobix <dave@quobix.com>
