-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: a parameter in the rolodex should be evaluated using the index that the node is in #336
Conversation
…hat the node is in
@ThomasRooney can you add a test to validate the correct behaviour |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #336 +/- ##
==========================================
- Coverage 99.65% 99.64% -0.02%
==========================================
Files 164 164
Lines 16674 16697 +23
==========================================
+ Hits 16616 16637 +21
- Misses 53 55 +2
Partials 5 5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Test added. Just fighting a "line count" snapshot test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to test this locally first before I approve, because it looks solid.
If you have fixed this race condition bug, I will owe you a bottle of whiskey.
I tested it, seems to work fine - however the bug is still there, when setting So, the hunt still continues, but this LGTM. |
This fixes vacuum rules that lookup operations in the index where:
./paths/mypath.yaml
./components.yaml#/path-item
What was previously happening in [2] is that the
./components.yaml
was being resolved in./components.yaml
(the parent directory) instead of./paths/components.yaml
(the right directory). This resulted in a failure to evaluate path item references and unexpected linting failures.This changes adjusts the lookup to search through the index's nodeMap to find the location of the YAML
$ref
node value that's been evaluated. Once we find it, we lookup the associated index of that file and do a seek in that specific index.We also fix a race condition with resolving the specification asyncronously -- if we are going to an external ref we must do it sequentially as otherwise an index might be added multiple times during an async
FindComponent
call. This latent bug was exposed as we tested this.