kunwp1 opened a new pull request, #5565: URL: https://github.com/apache/texera/pull/5565
## Purpose Closes #3120. The websocket state on the front end did not clear when the user returned to the dashboard. Entering another workflow then re-opened the websocket in its previous state. As noted in the issue, #3093 fixed the in-canvas re-open (same `wid` reused) but did not cover the `wid -> null -> wid` sequence that occurs on a dashboard round-trip. ## Root cause `WorkflowWebsocketService` and `ComputingUnitStatusService` are both `providedIn: "root"` singletons, so their state outlives the workspace. `WorkspaceComponent.ngOnDestroy()` — the exit point when navigating back to the dashboard — persisted the workflow and cleared the graph but **never tore down the websocket**. The socket stayed open and the connection-tracking state (`currentConnectedWid` / `currentConnectedCuid`, the `selectedUnitSubject` `BehaviorSubject`, and `numWorkers`) remained populated. On re-entry, `ComputingUnitStatusService.selectComputingUnit()`'s guard ```ts const shouldReconnect = this.currentConnectedCuid !== cuid || this.currentConnectedWid !== wid; ``` saw the retained values, so for the **same workflow** (`wid -> null -> wid`) it returned `false` and the stale socket was reused. The stale `selectedUnitSubject` also replayed the previous unit to the power button. ## Changes - **`computing-unit-status.service.ts`** — new `disconnect()` that closes the socket, clears operator status, stops the selected-unit polling, resets `currentConnectedWid` / `currentConnectedCuid`, and resets the selected unit to `null`. - **`workspace.component.ts`** — `ngOnDestroy()` calls `disconnect()`, so leaving the workspace tears down the connection and re-entering any workflow (same `wid` included) starts from a clean reconnect. - **`workflow-websocket.service.ts`** — `closeWebsocket()` resets `numWorkers = -1`, since the worker count comes from the live connection and is stale once the socket is gone. ## Tests - New `computing-unit-status.service.spec.ts` with a regression test for #3120: after `disconnect()`, re-selecting the **same** `(wid, cuid)` reconnects. Verified it fails (`openWebsocket` called 1× instead of 2×) when the connection-tracking reset is reverted, and passes with the fix. - New cases in `workflow-websocket.service.spec.ts` (`numWorkers` reset on close) and `workspace.component.spec.ts` (`ngOnDestroy` calls `disconnect`). - `29/29` tests pass across the three affected specs; `eslint` and `prettier --check` clean on all changed files. ## Scope note This fix targets the websocket **connection layer**, which is what re-opens "in its previous state." The execution-status / console / result panels are also websocket-driven root singletons; they were left out because `ExecuteWorkflowService` has a circular dependency with `ComputingUnitStatusService`, and a clean reconnect repopulates them anyway. Happy to extend `ngOnDestroy` to also blank those panels on exit if reviewers prefer the broader reading of "every state related to websocket." --- *AI-assisted: investigation, implementation, and tests were developed with Claude Code, then reviewed and verified by the author.* 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
