Matthew-DWM opened a new issue, #9105: URL: https://github.com/apache/texera/issues/9105
### What happened? When execution is paused on a line that has no breakpoint of its own (after **Step**, or after removing the breakpoint you were stopped on), adding a breakpoint on that line goes wrong. Clicking the line's gutter hangs the worker until the run is killed. Typing `break N` for that line in the Console tab makes the run resume by itself, and the breakpoint it sets is never drawn. Both come from one place: the paused line keeps a debug-state entry with `hit: true` and no breakpoint ID, which two handlers mistreat. ``` Before: paused on 12, no breakpoint -> click 12 -> "clear " -> pdb waits on stdin -> worker hangs After: paused on 12, no breakpoint -> click 12 -> "break 12" -> ack -> dot drawn, still paused Before: paused on 12, no breakpoint -> Console break 12 -> ack -> entry reset to not hit -> "continue" sent -> run resumes, no dot After: paused on 12, no breakpoint -> Console break 12 -> ack -> dot drawn, still paused ``` **Expected:** adding a breakpoint on the paused line, by clicking or from the Console, sets it, draws its dot, and leaves execution paused. **Cause:** three places in the frontend. 1. [`doModifyBreakpoint`](https://github.com/apache/texera/blob/57faa6b85c72bdd258b8e735c4be13171b5f8443/frontend/src/app/workspace/service/operator-debug/udf-debug.service.ts#L106-L119) sends `clear` for any line that has an entry, followed by the breakpoint ID or an empty string. In `pdb`, a bare `clear` calls Python's `input('Clear all breaks? ')`, which reads the worker process's own standard input. Nothing writes to it, so the debugger blocks and no later command gets a reply. The spec ["should clear a breakpoint that lost its id with an empty id"](https://github.com/apache/texera/blob/57faa6b85c72bdd258b8e735c4be13171b5f8443/frontend/src/app/workspace/service/operator-debug/udf-debug.service.spec.ts#L489-L503) pins that payload. 2. The [breakpoint-confirmation handler](https://github.com/apache/texera/blob/57faa6b85c72bdd258b8e735c4be13171b5f8443/frontend/src/app/workspace/service/operator-debug/udf-debug.service.ts#L188-L206) replaces the line's entry with `hit: false`. With nothing marked as hit any more, it sends `continue` to every worker, so the run resumes. 3. The code editor's [update branch](https://github.com/apache/texera/blob/57faa6b85c72bdd258b8e735c4be13171b5f8443/frontend/src/app/workspace/component/code-editor-dialog/code-debugger.component.ts#L182-L195) redraws only when `hit` or the condition changes, so an entry that gains a breakpoint ID gets no dot. **Possible fix:** in `doModifyBreakpoint`, treat an entry without a breakpoint ID as "no breakpoint" (send `break N`, and never a bare `clear`). When recording the confirmation, keep the entry's existing `hit`, so the automatic `continue` is skipped while paused. In the editor, draw or remove the dot when an entry's breakpoint ID appears or disappears. Fixing only the first makes a click behave like the Console path. Found while verifying the fix for #3830. ### How to reproduce? Setup: create a workflow with a Python UDF whose code runs for a while, e.g. a loop with `time.sleep(1)`. Run it, open the code editor, and click the gutter beside a line in the loop. Execution pauses on that line. Click (the worker hangs): 1. In the Console tab of the result panel, press **Step**. The highlight moves to the next line, which has no dot. 2. Click that highlighted line's gutter. The Console tab shows `clear` with no number, and nothing comes back. 3. Press **Continue**: no reply. The highlight disappears, but the operator stays Paused until **Kill**. The same happens if you click the dot of the breakpoint you are stopped on (removing it), then click that line again. Console (the run resumes): 1. Press **Step**, as above. Execution pauses on the next line. 2. In the Console tab's command box, type `break <that line number>` and press Enter. `pdb` confirms `Breakpoint 2 at …`, the browser sends `continue` right after it, and execution runs on to the first breakpoint. No dot appears on the line. 3. Press **Continue**. Execution stops on that line, at a breakpoint the editor doesn't show. ### 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]
