In vacuum, a usecase was reported where an infinite loop occurred due to re-parsing the same reference over and over in a loop. It was re-creatable and it was because the loop happened before the index was ready.
This should be resolved now, at least for this use case. To be sure, I have included the specs as a new test.
https://github.com/daveshanley/vacuum/issues/268
Signed-off-by: Dave Shanley <dave@quobix.com>
Tests all passing, runs super fast, pulls in every single DigitalOcean spec and parses it. There may be some issues deeper down in the models, but for now high level tests all pass.
Thinking more about how to know what to resolve and what not to means depending on circular reference knowledge. So using an idea from @TristanSpeakEasy, the `*resolver.ResolvingError` now contains a pointer to the original circular error, and it also implements the `Error` interface correctly which allows it simple passage up the chain, without losing fidelity.
Added new documentation example as well
Signed-off-by: Dave Shanley <dave@quobix.com>
A single line that tries to read an HTTP response body and fails is very hard to test without mocking, and the mock does not add value to a single line of code to check for an error that can rarely ever be triggered. Going to settle for 99.9% for now.
Using some designs unearthed from building the higher level model, I have brough that design down to the lower level to speed things up. It only took 8 years, but finally, I think I have mastered mult-threading. No more deadlocks, and no more need for waitgroups for everything.
Building out models that have circular references is tricky. Particularly when they are polymorphic ones. The resolver now searches the polymorphic references for circular references as well (which is returning much more valuable results now). The low level model is now sensitive to this and will avoid building out anything that is circular.
