You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a scenario that happened to a user and we could surface better errors
Current behavior
Take a look at the type annotations for external_input. The current dataflow definition is valid because the types are deemed equivalent (Any is special, it is both a subclass and super class of all types, including MyClass)
The problem happens when calling Driver.execute(...) and specifying external_input. If the user expects it to take Any and pass a value that's not MyClass, the input validation will say that there's a type mismatch without more details.
Additionally, because of the way visualizations are rendered, the two external_input will appear with the same type despite being annotated differently.
Also, the problem is specific to inputs. The following DAG wouldn't raise an error despite the object not matching the annotated type because there's no runtime type validation by default:
we could have better errors on input type validation
we could warn that nodes are annotated differently but with valid types at Builder.build() time
display the different type annotations in the visualization (I suggest against because it would be confusing since it can only be "one type at a time")
The text was updated successfully, but these errors were encountered:
This is a scenario that happened to a user and we could surface better errors
Current behavior
Take a look at the type annotations for
external_input
. The current dataflow definition is valid because the types are deemed equivalent (Any
is special, it is both a subclass and super class of all types, includingMyClass
)The problem happens when calling
Driver.execute(...)
and specifyingexternal_input
. If the user expects it to takeAny
and pass a value that's notMyClass
, the input validation will say that there's a type mismatch without more details.Additionally, because of the way visualizations are rendered, the two
external_input
will appear with the same type despite being annotated differently.Also, the problem is specific to
inputs
. The following DAG wouldn't raise an error despite the object not matching the annotated type because there's no runtime type validation by default:Potential solutions
Builder.build()
timeThe text was updated successfully, but these errors were encountered: