Matthew-DWM opened a new pull request, #9030: URL: https://github.com/apache/texera/pull/9030
### What changes were proposed in this PR? Right after creating a new workflow, a breakpoint in a Python UDF did nothing until the page was refreshed. Two lifecycle bugs in the frontend caused it: 1. `UdfDebugService` is provided in root but set up debug state and handlers only for the operators present when it was first injected. A new or reopened workflow gets a fresh shared document, so a UDF added later had no debug state: the gutter click threw `operator … does not have a debug state` and nothing was sent. 2. `CodeDebuggerComponent` never removed its Y.Map observer. An editor opened before the run (to write the code) and closed left one behind that threw when pdb confirmed the breakpoint, which skipped the automatic `continue`: the dot appeared but the run never stopped there. ``` Before: new workflow -> UDF has no debug state -> gutter click throws, nothing sent After: new workflow -> state created on first use -> break -> ack -> continue -> stops at the line Before: editor closed before the run -> its observer stays -> throws on the ack -> no continue After: editor closed before the run -> observer removed -> ack -> continue -> stops at the line ``` - The service registers its handlers once, routes console messages by operator ID, and creates an operator's debug state on first use, in the open document. - The component unobserves on destroy, draws nothing while breakpoints are off, starts from `getCurrentState()` (an editor opened mid-run waited for the next status update), and restores the paused line when reopened. - When a run ends or the editor closes, the component removes its own breakpoint and highlight decorations (`clearBreakpoints()`), since `MonacoBreakpoint.dispose()` drops its editor first and left them on the model, and closes the breakpoint condition input. The dots therefore disappear when a run ends instead of staying drawn but inactive. #### Before (main) The issue's steps: a new workflow with a Python UDF that calls `time.sleep(0.5)`, run, open the code editor, click the gutter. No breakpoint is set. https://github.com/user-attachments/assets/480b164d-8ed4-46bb-8b38-5a969aa0fd74 #### After (this PR) The same steps, with no refresh: the dot appears, the Console tab shows `break` → `Breakpoint 1 at …` → `continue`, and execution pauses on the line. **Step** moves to the next line and **Continue** runs on to the breakpoint again. https://github.com/user-attachments/assets/4b96b63c-e089-49cf-90d0-2c2863d3ea2a ### Any related issues, documentation, discussions? Closes #3830 ### How was this PR tested? Added regression cases to `udf-debug.service.spec.ts` (service created before the graph: operator added later, "create new", reopened workflow, deleted or unknown operator, zero and two workers, and a closed pre-run editor no longer blocking `continue`), `code-debugger.component.spec.ts` (opened while running or paused, closed editor, condition input closed, and no breakpoint or highlight left on a real Monaco model) and `workflow-graph.spec.ts` (`hasOperatorDebugState`). The lifecycle cases fail without the fix. ``` cd frontend yarn ng test --watch=false --include='**/udf-debug.service.spec.ts' --include='**/code-debugger.component.spec.ts' --include='**/workflow-graph.spec.ts' yarn test:ci # Test Files 236 passed, Tests 6661 passed | 1 skipped yarn ng run gui:test-browser --watch=false # Test Files 3 passed, Tests 23 passed yarn format:ci yarn build:ci ``` Manual check on a local stack, following the issue's video: 1. Create a new workflow and add a Python UDF. In its code editor, add `time.sleep(0.5)` to the loop, then close the editor. 2. Run the workflow, and once the UDF is running, open its code editor again. 3. Click the gutter beside a line in the loop. The dot appears, the Console tab of the result panel shows `break` → `Breakpoint 1 at …` → `continue`, and execution pauses on that line, with no page refresh. 4. In the Console tab, **Step** moves the highlight to the next line, and **Continue** runs on to the breakpoint again. An automated browser run against the same stack also covered the toolbar's "create new" and the dashboard's "Create Workflow" in the same tab, a reopened workflow, a regular Python UDF fed by a source, a conditional breakpoint, closing and reopening the editor while paused, clearing a breakpoint, and kill and rerun without a refresh. On main the same steps set no breakpoint, or show a dot the run never stops at. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5.5) -- 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]
