Flyte enables production-grade orchestration for machine learning workflows and data processing created to accelerate local workflows to production.

Flyte

I'm getting a typing complaint while writing an integration test for a workflow: :thread:

This is broadly the test case:
```from our.codebase.task import task, OurParameterType, OurTaskResult

def test_our_task():
    @workflow
    def do_workflow(arg1: FlyteDirectory, arg2: OurParameterType) -&gt; OurTaskResult:
        return task(arg1, arg2)

    arg1 = foo
    arg2 = bar

    ret: OurTaskResult = do_workflow(arg1, arg2)```

Two typing issues occur:
1. `no parameter named arg2` 
2. `VoidPromise is incompatible with OurTaskResult`

In the case of #1, is this some byproduct of the decorator?

in the case of #2 should the return type of `do_work` be something else?

`OurTaskResult` is essentially a:

```@dataclass_json
@dataclass
class FlyteResult:
  result: &lt;our dc&gt;```
Where `our dc` is passed during module evaluation

<@U036GA8565T>. in the case of #1, workflows and tasks only accept named arguments. Can you try replacing the invocation of `do_workflow` with:
```do_workflow(arg1=arg1, arg2=arg2)```
As for #2, this is a byproduct of the flytekit decorators. I think we can do something there, but will require a few changes.

Thanks <@U0265RTUJ5B> - we actually are passing with keyword args - sorry, that was just me not being precise in my example

got it, thanks for clarifying.
And just so I understand, the test fails or this is about the types not matching (and mypy complaining)?

got it. Yeah, we'll need to make some changes to the workflow decorator to ensure mypy/pyright is happy.

<@U0265RTUJ5B> is this a bug or housekeeping? Feels like housekeeping honestly because things work

<https://github.com/flyteorg/flyte/issues/2525>

Amazing, thanks. Will ping here when we figure out priorities. In the meantime, if you want to take a crack at it, please feel free.