pedroreyesalavrado opened a new issue, #8662: URL: https://github.com/apache/texera/issues/8662
### Feature Summary When a Python UDF raises, Texera surfaces the traceback in the console and stops there. The user has to read the traceback, map it back to a column name or a type in the input schema, scroll up to the operator's code, edit it by hand, and re-run. For the most common failure modes this round-trip is mechanical, and it is the part of the loop new users get stuck on: the traceback names a symptom (`KeyError: 'genre'`) while the information actually needed to fix it (the input schema says the column is `genres`) lives in a different panel. This proposes a panel in the result area that reads the error and the operator's own context, proposes a concrete edit, and lets the user apply it with one click. Scope is deliberately narrow: four recognizable error classes, no new backend endpoints, no engine changes. ### Proposed Solution or Design A new "AI Fix" tab appears in the result panel when the selected operator has an error, alongside the existing Console and Result tabs. It is gated on the existing `workflowWorkspace.copilotEnabled` GUI config flag, so deployments without an LLM configured see no change. Flow: 1. The user clicks **Analyze** (explicit — nothing is sent anywhere until they do). 2. The panel gathers the operator context that already exists client-side: the error text from the console messages, the input port schema from the compilation service, and the operator's current code/properties. 3. It classifies the error against four patterns and sends a targeted prompt to the existing LiteLLM proxy (`/api/chat/completions`) — the same route the Copilot feature already uses. No new endpoint. 4. The response is shown as a **diff** against the current code or property value. Nothing is written to the workflow yet. 5. **Apply** writes the change through `WorkflowActionService` (so it is undoable and syncs to collaborators like any other edit) and re-runs the workflow. **Discard** returns the panel to idle. The four classes it handles, chosen because each has a fix derivable from context already on the client: | Error | Context used | | --- | --- | | `KeyError: '<col>'` | input port schema — suggests the closest real column | | `TypeError: unsupported operand` | attribute types — suggests the explicit cast | | `ValueError: Input contains NaN` / `NullPointerException` | suggests the guard / dropna | | model-not-found / `404` | the configured model list | Anything else is reported as unsupported rather than guessed at. Safety properties worth calling out: - The suggestion is checked against the live operator state before it is applied; if the code or field changed since the suggestion was generated, the apply is refused rather than silently overwriting the newer value. - If the deployment requires a warehouse and none is selected, the fix is applied but no run is claimed, since `ExecuteWorkflowService` would refuse it. ### Affected Area Workflow UI -- 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]
