Skip to content
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 in fillVars #3505

Merged
merged 6 commits into from
Jun 11, 2019
Merged

Fix panic in fillVars #3505

merged 6 commits into from
Jun 11, 2019

Conversation

pawanrawal
Copy link
Contributor

@pawanrawal pawanrawal commented Jun 3, 2019

This fixes #3470. Test cases have been added to verify the fix. The default case in fillVars seemed hacky because it was assigning a value corresponding to uid 0 in uidToVal, that has been removed. The code in the query package needs more work to clarify what the invariants are but that would be part of another PR.


This change is Reviewable

@pawanrawal pawanrawal requested review from manishrjain and a team as code owners June 3, 2019 07:29
@pawanrawal pawanrawal requested a review from mangalaman93 June 3, 2019 07:33
Copy link
Contributor

@martinmr martinmr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Just some minor comments.

Reviewed 4 of 4 files at r1.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @mangalaman93, @manishrjain, and @pawanrawal)


query/query.go, line 346 at r1 (raw file):

}

func emptyIneqFnWithVar(sg *SubGraph) bool {

minor: maybe rename this to isEmpty... so that it's clear from the name that the function returns a bool.


query/query.go, line 1665 at r1 (raw file):

 which could be run

change to something like "which were able to run" or "which were successfully run"

"which could be run" is a bit ambiguous. It might be interpreted as "which might be run", meaning the other queries have not been processed yet.


query/query.go, line 1716 at r1 (raw file):

				return errors.Errorf("Wrong variable type encountered for var(%v) %v.", v.Name, v.Typ)

			default:

maybe add a glog.V(2) statement to track this branch was reached.

Copy link
Contributor

@manishrjain manishrjain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm: Address @martinmr 's comments and this is good to go. I'm super glad that we're making the len vs nil differentiation correctly here.

@pawanrawal can you look at other changes like these which were trying to fix the broken-ness introduced by the original discussed change.

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @mangalaman93, @martinmr, and @pawanrawal)


query/query.go, line 1716 at r1 (raw file):

Previously, martinmr (Martin Martinez Rivera) wrote…

maybe add a glog.V(2) statement to track this branch was reached.

Please don't add glog output on queries in anything under glog.V(3).

Copy link
Contributor Author

@pawanrawal pawanrawal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure @manishrjain, will have a look at other usages too. I have addressed the comments and am merging this change. Will open a separate PR against release/v1.0.

Reviewable status: 3 of 4 files reviewed, 2 unresolved discussions (waiting on @mangalaman93 and @martinmr)


query/query.go, line 1665 at r1 (raw file):

Previously, martinmr (Martin Martinez Rivera) wrote…
 which could be run

change to something like "which were able to run" or "which were successfully run"

"which could be run" is a bit ambiguous. It might be interpreted as "which might be run", meaning the other queries have not been processed yet.

Done.


query/query.go, line 1716 at r1 (raw file):

Previously, manishrjain (Manish R Jain) wrote…

Please don't add glog output on queries in anything under glog.V(3).

Done.

@pawanrawal pawanrawal merged commit c72b8da into master Jun 11, 2019
@pawanrawal pawanrawal deleted the pawanrawal/fix-3470 branch June 11, 2019 11:55
pawanrawal added a commit that referenced this pull request Jun 12, 2019
This fixes #3470. Test cases have been added to verify the fix. The default case in fillVars seemed hacky because it was assigning a value corresponding to uid 0 in uidToVal, that has been removed and appropriate changes have been made at other places.
dna2github pushed a commit to dna2fork/dgraph that referenced this pull request Jul 19, 2019
This fixes dgraph-io#3470. Test cases have been added to verify the fix. The default case in fillVars seemed hacky because it was assigning a value corresponding to uid 0 in uidToVal, that has been removed and appropriate changes have been made at other places.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Regression with queries that use value variables causing panics
3 participants