We just updated from Flyte release

v0.19.3

to new

v1.0.0

and Flyte Admin no longer wants to register workflows like:

@flytekit.workflow
def DDPTrainingWorkflow(
    train_datasets: typing.List[str] = [],
    ...
):
    patch_experiment(train_datasets)

@flytekit.task()
def patch_experiment(
    train_datasets: typing.List[str],
)

^^^^ while registering the workflow, this throws:

[2022-04-27T15:09:25Z] 	details = "Type mismatch for Parameter train_datasets in default_inputs has type collection_type:<simple:STRING > , expected simple:NONE "

clearly something doesn't like the default

[]

value of

train_datasets

against its declared type

typing.List[str]

. Ideas?

cc @thankful-minister-83577 @high-accountant-32689

Users are using flytekit 0.23.0b6. The error message is in a gRPC response (so it is coming as part of a response from admin and not from flytekit itselft)

Ouch... You're absolutely right! Apologies about the breakage.. we will get right on it. This should be as simple as adding an example in flytesnacks/cookbook/core. All of these get automatically run with every release. Mind filing an issue to do that? Cc @high-accountant-32689 to keep me honest ^ Cc @tall-lock-23197 to help add the example for how to use default inputs for workflows and launchplans...

I do get this on both flytekit

0.23.0b6

and

0.32.3

. I can't easily upgrade to flytekit 1.0.0 yet.

@astonishing-lizard-78628 this is indeed embarassing. Let me try it out. We have not changed the compiler logic

Is there an easy way I can tell users to redeclare the default value of their workflow parameter, e.g.

@flytekit.workflow
def DDPTrainingWorkflow(
    train_datasets: typing.List[str] = ???,  # was previously []
):

no

x: typing.List[str] = []

should work

@freezing-airport-6809, what about non-empty lists as defaults? Does that work?

hmm let me check

Thanks for the update, I follow the issue

@astonishing-lizard-78628, we just released flyte 1.0.1. Can you update and verify that it fixes this issue on your side?

@high-accountant-32689 the issue is not solved currently in Flyte. Although a fix was recently made to Propeller, the issue actually appears to users at task / workflow registration time, which means that more fixes will need to be made to flytekit / flyteadmin.

@astonishing-lizard-78628, The Flyte 1.0.1 release contains the necessary changes to fix this, namely this flytepropeller PR and the corresponding flyteadmin PR. In terms of versions, we fixed the issue in flytepropeller v1.1.1 and flyteadmin v1.1.2, both of which were present in the flyte 1.0.1 release. Can you double-check which version of flyteadmin you're running?

Ah, I have been watching the flyteadmin PRs and didn't realize that the fix for the default values was embedded in the PR to which you linked. Let me see if I can verify the fix in my local cluster.

Awesome. We will make sure to include tests to cover this feature going forward.