This diff makes direct invocation call the underlying python function instead of the compute_fn.
Re-adjusted tests to account for new state of the world. Some tests exist to document that we don't catch incorrect behavior.
I guess if the decorated fxn isn't a generator we can validate, and then if it is a generator, we wrap it in another generator that performs the validation?
and if its async you wrap it an async generator that does the validation i think
I *think* validating outputs is a behavior we want, I may have my_solid() == my_val correct in test but if my typehint or OutputDefinition is wrong the test will no longer catch that
is there a wrong_type test somewhere here I am missing?
maybe @owen has an opinion from working on this recently, but would it make sense to just not do this wrapping here and instead allow compute_fn to simply be the decorated_fn and move the coercion code from decorator business to runtime?
should we drop passing positional_inputs and context_arg_provided and just resolve them from the decorated_fn if we are passing it here now?
assuming the wrapped compute_fn thing isn't used in any context other than the runtime pipeline execution, I didn't see a real reason to do it beforehand.
nit: "directly invoked"
took me way too much to figure out whats up with this, add a comment or maybe make a DecoratedSolidFunction subclass DecoratedLambdaSolidFunction that overrides to False
positional_inputs should get cleaned up the same way
|300–303 ↗||(On Diff #39567)|
|192–193 ↗||(On Diff #39567)|