Matthew-DWM opened a new issue, #9106: URL: https://github.com/apache/texera/issues/9106
### What happened? Breakpoint state outlives the run it belongs to, so the code editor shows breakpoints that the current (or a killed) worker does not have. After a kill, the paused operator never receives a final status, so the editor keeps treating it as Paused. After a page refresh, the old state comes back from the collaboration server and is never reset. Clicking such a dot sends `clear 1`, which gets no reply (kill) or `*** Breakpoint number 1 out of range` (refresh), and the dot stays. ``` Before: kill / refresh -> old breakpoint still drawn -> click -> clear 1 -> no reply / "out of range" -> stuck After: kill / refresh -> debugger state reset -> no stale breakpoints -> click -> break -> ack -> continue ``` | Trigger | What you see | | --- | --- | | **Kill** while paused on a breakpoint | The dot and the paused-line highlight stay, and the gutter stays active. Clicking the dot sends `clear 1` to a worker that no longer exists, so nothing replies and the dot stays, even after reopening the editor. Running again clears it. | | **Refresh** the page, then run again | The previous run's dot is drawn on the new run. Clicking it sends `clear 1`, `pdb` answers `*** Breakpoint number 1 out of range`, and no "Deleted" reply ever comes, so that line stays stuck for the run. | **Expected:** when a run ends or a new one starts, the editor shows no breakpoints from the old run. **Cause:** debug state is not reset at the boundaries between runs, and the editor's gutter follows only the operator's status. - After a kill, the workflow becomes `Killed`, but the paused operator's status stays `Paused` because no final status arrives for it. The code editor enables its gutter while the operator is Running or Paused, so it stays on. - The debug state lives in the workflow's shared yjs document, which the collaboration server keeps, so a refreshed page gets the old entries back. At run start, [`resetStatus()`](https://github.com/apache/texera/blob/57faa6b85c72bdd258b8e735c4be13171b5f8443/frontend/src/app/workspace/service/workflow-status/workflow-status.service.ts#L134) only emits `Uninitialized` for operators already in its current state, which is empty right after a refresh, so `UdfDebugService` never clears them. **Possible fix:** clear every operator's debug state when an execution starts, and switch the editor's gutter off (removing its dots) when the execution reaches Killed, Completed or Failed, not only on the operator's status. Found while verifying the fix for #3830. ### How to reproduce? Kill: 1. Create a workflow with a Python UDF whose code runs for a while, e.g. `time.sleep(0.5)` in a loop. 2. Run it, open the code editor, and add a breakpoint inside the loop; let execution pause there. 3. Click **Kill**. 4. Click the red dot: the Console tab shows `clear 1`, nothing replies, and the dot and highlight stay. Close and reopen the code editor: they are still there. Refresh: 1. As above, add a breakpoint, let execution pause there, then kill the run. 2. Refresh the page and run the workflow again. 3. Open the code editor: the dot from the previous run is shown. Click it: the Console tab shows `clear 1`, then `*** Breakpoint number 1 out of range`, and the dot stays. ### Version/Branch 1.4.0-incubating-SNAPSHOT (main) ### Commit Hash (Optional) _No response_ ### What browsers are you seeing the problem on? _No response_ ### Relevant log output ```shell ``` -- 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]
