sshiv012 opened a new issue, #8736:
URL: https://github.com/apache/texera/issues/8736
### Feature Summary
Python UDF errors and the user docs are hard to follow for non-programmers.
The UMich team hit this directly: a workflow stayed in RUNNING with every
operator at 0 rows, and creating new computing units didn't help because the
cause was in the UDF code.
The code had a few small mistakes that Texera didn't explain:
1. `from pytexera import *` was missing. Our default template ships with
that line commented out, so this is easy to hit. The worker fails with `name
'UDFOperatorV2' is not defined`.
2. After an edit, the class inherited `UDFOperatorV2` but implemented
`process_table`. The only message was `There should be one and only one
Operator defined`, which doesn't say what is wrong.
3. There were also some quieter bugs:
- `return` instead of `yield`, which shows up as `pampy.MatchError: '_'
not provided` or `'NoneType' object is not iterable`
- `__init__` without `super().__init__()`, which shows up as
`'_TableOperator__table_data'`
The hang itself is being fixed in #8667 / #8668. Once that lands, users will
actually see these errors, so the errors need to make sense.
We also walked through the docs as a new user would. Several steps assume
things a first-time user won't know:
- The Operators and Result panels start closed.
- Errors from code that fails at startup only show up when nothing is
selected (the "Static Error" tab). Clicking the failed operator shows an empty
Console.
- The dataset tutorial still points to an `environment` tab that no longer
exists, and its sample CSV link returns 404.
### Proposed Solution or Design
Small, separate changes:
**Templates.** Keep `from pytexera import *` active in the Python UDF, 2-in
and 1-out templates. Add a short header comment:
```python
# Keep exactly ONE class below: uncomment it and delete the others.
# Its method must match its base class:
# UDFOperatorV2 -> process_tuple, UDFBatchOperator -> process_batch,
# UDFTableOperator -> process_table
# Always `yield` results (never `return`).
```
With that, uncommenting one class gives a working UDF.
**Load errors that say what to fix.** Examples:
- `... WrapperClass subclasses UDFOperatorV2 but does not implement
process_tuple. If you meant process_table, subclass UDFTableOperator instead.`
- `name 'UDFOperatorV2' is not defined (line 2 of the UDF code). Add from
pytexera import * at the top of the UDF.`
- `Found 2: FirstOperator, SecondOperator. Keep one and delete or comment
out the others.`
**Runtime errors.**
- `process_table must yield results, not return them.`
- Create the table and batch buffers lazily, so a missing
`super().__init__()` just works. `Operator` already does this for its template
decoder.
- Point output column mismatches to "Retain input columns" and "Extra output
column(s)".
**Small UI hints.**
- A tooltip on the Kill button.
- The empty Result panel says: "Click an operator to see its results and
Console. Click an empty spot on the canvas to see errors from all operators."
- The computing unit quota error suggests reusing or terminating a unit.
**Docs.**
- Rewrite the UDF guide, the "how to use Texera" guide and the dataset
tutorial, with current screenshots and a troubleshooting table that maps each
error message to its fix.
- Add short pages on computing units, sharing and permissions, and how
workflows run (blocking operators, regions).
### Affected Area
Python UDF runtime (pyamber), workflow operators (UDF templates), frontend
(menu, result panel), computing unit managing service, and docs.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
