-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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: SnapshotProvider
edge case scenarios on insertion and query
#6707
Conversation
3e43d1d
to
cf6350c
Compare
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.
just one q re var location
result.push(res); | ||
break 'inner | ||
} | ||
None => { | ||
if retrying { | ||
let err = if segment.is_headers() { |
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.
can we add a warn! here?
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.
we can, but this is not an actual malfunction, which I kinda associate with a warning.
if the range spans across multiple files, there will be a time when the number
no longer belongs to the current file (and thus returning None
on the get_fn
), and we need to find the associated file provider (get_provider
).
With that in mind, do you still want me to add a warn!? Maybe a trace! would be a better fit?
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.
oh wait you mean inside the if retrying
, yeah okay adding
This PR fixes two edge case scenarios.
get_or_create_jar_provider
: change from.insert
toentry
api. Although not encountered, it is possible that two parallel threads reach theself.map.insert
almost at the same time. The first one holding the lock would insert aLoadedJar
. The second one once unblocked, would do the same thing invalidating the previousLoadedJar
and potentially affecting the first threads task.fetch_range_with_predicate
: on a normal node behaviour it shouldn't happen, but when testing stuff out we have encountered this.