-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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(backend): fix simple loop bug #7578
Conversation
@@ -107,7 +107,7 @@ func Compile(jobArg *pipelinespec.PipelineJob, opts *Options) (*wfapi.Workflow, | |||
wf: wf, | |||
templates: make(map[string]*wfapi.Template), | |||
// TODO(chensun): release process and update the images. | |||
driverImage: "gcr.io/ml-pipeline-test/dev/kfp-driver:latest", | |||
driverImage: "gcr.io/ling-kfp/dev/kfp-driver:latest", |
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.
This should exist only in your local change. And this seems to be the cause of the unit test failure in presubmit.
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.
Should I upload my driver image onto the "gcr.io/ml-pipeline-test/dev/kfp-driver:latest" address? If I don't do that, the presubmit test would not pass.
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.
Not yet. Was it failing on samples-v2 test in presubmit? In that case, we can update the image when this PR is close the ready to merge state.
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.
Reverted it.
backend/src/v2/driver/driver.go
Outdated
return execution, report(fmt.Errorf("cannot find input parameter")) | ||
// Check the items type of parameterIterator: | ||
// It can be "inputParameter" or "Raw" | ||
value := structpb.NewNullValue() |
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.
nit: this null value initialization seems to be unnecessary?
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 think it is necessary. The variable needs to be declared outside the switch/case statement, then it can be assigned value inside the switch/case statements. If the variables were declared inside, it would not be accessible outside the statement. (Ref: https://stackoverflow.com/questions/21481288/variable-not-declared-inside-a-if-else-statement)
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.
The variable needs to be declared outside the switch/case statement, then it can be assigned value inside the switch/case statements.
You can still declare it inside a switch case/branch if it's not reused across multiple branches and not used outside the switch scope--didn't check if that's the case.
That said, my comments was more on the initialization part than the declaration part.
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.
It is being used outside the switch scope, so I guess it needs to be declared outside as well. Although I don't have to assign it a null value - I can just declare its type, I don't find a method in structpb
that just declares a Variable
type. It looks like they need to initialize some value inside the variable.
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.
It turned out that I can use var value *structpb.Value
for the declaration.
backend/src/v2/driver/driver.go
Outdated
// Check the items type of parameterIterator: | ||
// It can be "inputParameter" or "Raw" | ||
value := structpb.NewNullValue() | ||
var ok bool |
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.
nit: probably more common to use short variable declaration. E.g.:
value, ok := ...
if !ok {
...
}
or
if value, ok := ...; !ok {
...
}
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.
Got it, I will declare value
and ok
in the same line.
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.
Remove the declaration for ok
?
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.
The problem is, in line 454 (just 4 lines below), we need to assign values to both value
and ok
. Thus ok
has to be created beforehand.
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.
No, you could have
var value *structpb.Value
value, ok := ...
Short variable declaration works in this case.
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.
It still reports error though,
What error specifically?
probably because
value, ok := ...
line is not directly under the declaration of value, but inside a switch/case.
I don't think this would matter.
You can probably play around here: https://go.dev/tour/basics/10
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.
See an example here: https://go.dev/play/p/-LdL96A5GUV
If I use the :=
declaration inside the switch/case block, the value of value
that was assigned inside won't be accessible from outside.
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.
That's expected. But we were saying to keep the value
declaration as-is (we already settled on that one from another comment where I asked to remove the null value assignment and only keep the declaration). The comment above was to omit the ok
declaration on this line, because I don't think you need to read ok
outside the switch.
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.
Does that mean I declare ok
inside the switch?
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.
you're right on the value part, just a nitpick let's still move ok declaration inside the switch so it's close to where it is used.
backend/src/v2/driver/driver.go
Outdated
var ok bool | ||
switch iterator.GetItems().GetKind().(type) { | ||
case *pipelinespec.ParameterIteratorSpec_ItemsSpec_InputParameter: | ||
glog.Infof("ParameterIterator type: %T", iterator.GetItems().GetKind()) |
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.
nit: feels to me a bit excessive. Consider reducing some logs? (They may be helpful for debug process, but would they be necessary to log?)
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.
Makes sense! Will remove these.
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.
remove this and the below logs?
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.
OK, I will remove them.
backend/src/v2/driver/driver.go
Outdated
if !ok { | ||
return execution, report(fmt.Errorf("cannot find input parameter")) | ||
} | ||
glog.Infof("inputParameter value: %+v", value) |
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.
ditto: excessive logs (and below)
@chensun Updated the PR |
change the driver image back to the kfp container registry.
@chensun updated the PR |
/retest |
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.
/lgtm
/approve
Thanks!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chensun The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
\retest |
/test kubeflow-pipelines-samples-v2 |
1 similar comment
/test kubeflow-pipelines-samples-v2 |
* support IR YAML format in API * Check the error message and return false if it is not nil * update error message * fixed simple loop but need cleaning up * Deleted debug logs * remove logs and fix some format * fix static_loop_arguments * change the driver image change the driver image back to the kfp container registry. * change variable declaration * remove logs * remove log * move `ok` definition * change test file for debug purpose * change test for debug purpose * update sample test for static loop * update test file, remove code for debug
* support IR YAML format in API * Check the error message and return false if it is not nil * update error message * fixed simple loop but need cleaning up * Deleted debug logs * remove logs and fix some format * fix static_loop_arguments * change the driver image change the driver image back to the kfp container registry. * change variable declaration * remove logs * remove log * move `ok` definition * change test file for debug purpose * change test for debug purpose * update sample test for static loop * update test file, remove code for debug
Description of your changes:
Fix bug that simple loop does not work. It only does not work when there is static input.
Note: need to change line #110 in backend/src/v2/compiler/argocompiler/argo.go to use the
ml-pipeline-test
gcr address.Checklist: