fix(frontend): clean up websocket state when returning to the dashboard (#5565) ### What changes were proposed in this PR? Websocket-derived front-end state (the connection itself, plus the execution status, console output, and results built from its events) lives in singletons outside the workspace. It was never torn down in two cases, so stale state carried over: 1. **Returning to the dashboard** and re-entering a workflow reused the previous socket. The connection-tracking fields (`currentConnectedWid` / `currentConnectedCuid`) also survived, so the reconnect guard saw them unchanged, skipped reconnecting, and reused the stale socket. (#3120 — the case #3093 did not cover.) 2. **Switching computing units** inside the workspace left the previous unit's console, results, and execution status on screen. This PR clears that state at both points. **Workspace exit**: `WorkspaceComponent.ngOnDestroy()` now tears everything down: | Call *(new)* | Resets | | --- | --- | | `ComputingUnitStatusService.disconnect()` | closes the socket, clears operator status, stops the unit poll, resets the connection-tracking fields and the selected unit | | `ExecuteWorkflowService.resetExecutionAndWorkers()` | execution status and worker assignments | | `WorkflowConsoleService.clearConsoleMessages()` | console output | | `WorkflowResultService.clearResults()` | result caches and table stats | **Unit switch**: `ComputingUnitStatusService` emits a reset signal when it reconnects to a different unit, and `WorkspaceComponent` clears the same execution / console / result state in response. As a result, switching units now discards the previous unit's results and console instead of leaving them on screen. The remaining websocket-event consumers need no teardown: `OperatorReuseCacheStatusService` is stateless, and `udf-debug.service`'s state lives in the `TexeraGraph`, already reset by `clearWorkflow()`. ### Any related issues, documentation, discussions? Closes #3120. Related: #3093 (earlier partial fix for the in-canvas socket re-open). ### How was this PR tested? Test with this workflow [Untitled workflow (14).json](https://github.com/user-attachments/files/28696700/Untitled.workflow.14.json) https://github.com/user-attachments/assets/060fe1ac-39cf-45e5-b423-5aa27fe17aed ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 4.8) --------- Co-authored-by: Xinyuan Lin <xinyual3@uci.edu>
Apache Texera (Incubating) is an open-source platform for human-AI collaborative data science using visual workflows. It enables human analysts to construct, execute, and refine data analysis tasks through an intuitive GUI, assisted by AI agents that understand natural-language instructions. Texera is well suited for a wide range of applications, including “AI for Science,” by making advanced AI and data science capabilities accessible to a broader community. It can run on a laptop for local use or be deployed in the cloud to support scalable processing of large datasets.
The platform has the following key features:
Please cite Texera as
@article{DBLP:journals/pvldb/WangHNKALLDL24, author = {Zuozhi Wang and Yicong Huang and Shengquan Ni and Avinash Kumar and Sadeem Alsudais and Xiaozhen Liu and Xinyuan Lin and Yunyan Ding and Chen Li}, title = {Texera: {A} System for Collaborative and Interactive Data Analytics Using Workflows}, journal = {Proc. {VLDB} Endow.}, volume = {17}, number = {11}, pages = {3580--3588}, year = {2024}, url = {https://www.vldb.org/pvldb/vol17/p3580-wang.pdf}, timestamp = {Thu, 19 Sep 2024 13:09:37 +0200}, biburl = {https://dblp.org/rec/journals/pvldb/WangHNKALLDL24.bib}, bibsource = {dblp computer science bibliography, https://dblp.org} }