Fix: Improve error handling in workflow compilation when output binding fails

[fg91]

Why are the changes needed?

@workflow
def wf() -> tuple[str, str, str]:
    return "foo", "bar", None

When registering this workflow, one gets the following obvious error:

~ pyflyte register test_wf.py
...
Python value cannot be None, expected <class 'str'>/<FlyteLiteral simple: STRING>

However, the exception does not hint which workflow/output is causing the error. In a large workflow with numerous sub workflows and dozens of tasks, it took one of our ML engineers quite some time to figure out where exactly the return was missing. They asked whether we could make this simpler.

What changes were proposed in this pull request?

I propose to catch errors raised by binding_from_python_std in the PythonFunctionWorkflow's compile function just as is done e.g. here.
This way, finding the error would have been a no-brainer.

How was this patch tested?

For the example workflow above, the error message now is:

~ pyflyte register test_wf.py
...
Failed to bind output o2 for function test_wf.wf: Python value cannot be None, expected <class 'str'>/<FlyteLiteral simple: STRING>

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (6cd0a60) 85.98% compared to head (ea81962) 82.53%.
Report is 79 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2047      +/-   ##
==========================================
- Coverage   85.98%   82.53%   -3.46%     
==========================================
  Files         308      313       +5     
  Lines       22946    23602     +656     
  Branches     3468     3535      +67     
==========================================
- Hits        19731    19479     -252     
- Misses       2615     3498     +883     
- Partials      600      625      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kumare3]

@wild-endeavor should these be AssertionErrors? or FlyteExceptions?

[fg91]

I used AssertionError in analogy to how it is done here but I'm happy to change to FlyteException if you prefer.

[fg91]

Let's do it like this 50ac42f?

[kumare3]

one comment else lgtm