Channels
#ask-the-community
Title
# ask-the-community
m
Martin Hwasser
10/21/2022, 12:29 PMHi, I have a strange error where I am creating several LaunchPlans with different names using
flytekit.LaunchPlan.get_or_createa-cst-oldError: rpc error: code = InvalidArgument desc = missing nameFWIW I have attached the protobuf here:
s
Shivay Lamba
10/21/2022, 3:44 PMHi Martin, for your question. We do have a execution validator for checking workflow names: https://github.com/flyteorg/flyteadmin/blob/7b48c856e3a1e12c57f1abbf535bf6c29fa59d74/pkg/manager/impl/validation/execution_validator.go#L19
But @Kevin Su or @Prafulla Mahindrakar could add to it
p
Prafulla Mahindrakar
10/26/2022, 4:46 PMHi @Martin Hwasser thats a very strange issue . Will need to check more on it . Also regarding deletion, currently we dont have a delete functionality in flyte and every object in flyte can be archived . This is by design i think . You can always choose to delete the archived ones from the DB .
So strange comes due to unmarshalling this proto works for both TaskSpec and Launchplan object.
``````
Following test demonstrates it. I am assuming you are using flytectl to register where you see this error.
Copy code
func TestUnmarshalProtoLaunchPlan(t *testing.T) {
pbBytes, err := os.ReadFile("/Users/praful/Downloads/17_a-cst-old_3.pb")
lp := &admin.LaunchPlan{}
err = proto.Unmarshal(pbBytes, lp)
assert.Nil(t, err)
assert.Equal(t, "a-cst-old", lp.Id.Name)
}
func TestUnmarshalProtoTaskSpec(t *testing.T) {
pbBytes, err := os.ReadFile("/Users/praful/Downloads/17_a-cst-old_3.pb")
lp := &admin.TaskSpec{}
err = proto.Unmarshal(pbBytes, lp)
assert.Nil(t, err)
assert.Equal(t, "a-cst-old", lp.Template.Id.Name)
}@Martin Hwasser may be you can share the updated proto where this works for you and we can run both test on it. I bet it fails the 2nd test and hence it works for you.
flytectl register relies on the fact the object will be one of the following types and not multiple
• admin.LaunchPlan
• admin.WorkflowSpec
• admin.TaskSpec
In your case the proto is able to be unmarshalled without error into Launchplan and TaskSpec type and taskSpec type gets precedence in flytectl code and thats the one thats gets sent to admin for registration and fails since the Name field in the unmarshalled taskSpec proto is empty .
If you unrmarshal it with Launchplan it has the correct Id.Name field
Cc: @Haytham Abuelfutuh
h
Haytham Abuelfutuh
10/28/2022, 5:50 PM
I downloaded an example from flytesnacks releases. And I do not see a way to distinguish between types based on the file.
I believe the protocol based on such convention is not good enough… I can think of two ways to improve the package -> register behavior:
1. Change the naming of these files to include a prefix informing flytectl/pyflyte register about how to parse these (e.g. `1_tsk_blast`… `2_wf_blast`… etc.).. This change will need to happen in all SDKs (python, java, scala)… the register behavior will need to be backward compatible…
2. Create an envelope message for the data serialized in these files… something like below. And update the registration logic to always only unmarshal into that envelope type.
Copy code
message RegistrationEntity {
oneof item {
TaskTemplate task = 1;
WorkflowTemplate workflow = 2;
...
}
}p
Prafulla Mahindrakar
11/01/2022, 6:39 AMCreated an issue here https://github.com/flyteorg/flyte/issues/3042
2 Views