-
Notifications
You must be signed in to change notification settings - Fork 43
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: Panic with different composite-indexed child objects #2947
fix: Panic with different composite-indexed child objects #2947
Conversation
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 trust it fixes it, but it is not clear why - please add some documentation :)
To me this makes it sound like the previous index iterator should be closed on |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2947 +/- ##
===========================================
- Coverage 79.26% 79.25% -0.02%
===========================================
Files 326 326
Lines 24870 24870
===========================================
- Hits 19713 19709 -4
Misses 3740 3740
- Partials 1417 1421 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 20 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Merge 2 index iterators into one.
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.
Looks good to me, thanks Islam :)
Please have a quick look at the final suggestion before merge.
func (iter *indexPrefixIterator) Init(ctx context.Context, store datastore.DSReaderWriter) error { | ||
iter.ctx = ctx | ||
iter.store = store | ||
iter.resultIter = nil |
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.
suggestion: If iter.resultIter
is not nil here, it looks like it should probably be closed before clearing the ref?
I have a vague memory of the normal fetcher failing because of this some time ago, but I might be wrong.
// create multinode | ||
multinode := ¶llelNode{ | ||
// create parallelNode | ||
parallelNode := ¶llelNode{ |
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.
praise: I forgot to add to my earlier review, thanks for renaming this.
// | ||
// NOTE: calling Init() on multiScanNode is subject to counting as well and as such | ||
// doesn't not provide idempotency guarantees. Counting is purely for performance | ||
// reasons and removing it should be safe. |
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.
praise: This is very clear, thanks Islam :)
// The issue was that [multiScanNode] that keeps track of how many calls to [Next()] should | ||
// be made, would call [Init()] and [Start()] every time without tracking, which would result | ||
// in child nodes being initialized and started multiple times, which in turn created | ||
// index iterators without closing them. |
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.
praise: Thanks for taking the time to link this to the ticket, it highlights the importance of the test very nicely.
Relevant issue(s)
Resolves #2924
Description
Make multiScanNode keep track of all calls.
The issue was that multiScanNode that keeps track of how many calls to Next() should be made, would call Init() and Start() every time without tracking, which would result in child nodes being initialized and started multiple times, which in turn created index iterators without closing them.