aicam opened a new issue, #6239: URL: https://github.com/apache/texera/issues/6239
### What happened? The Texera frontend leaks `y-websocket` (`/rtc`) connections to the shared-editing server. During a collaborative editing session (roughly a dozen users co-editing at once), the number of established connections to the y-websocket server grows far out of proportion to the number of users and keeps climbing while people edit. Once a gateway/proxy's per-cluster connection limit is reached, new upstream connections are refused, so users **stop seeing each other's cursors** and awareness/presence stops syncing for anyone who (re)connects. Symptoms: - Tens of connections per user (far more than the expected ~1 per open tab). - The connection count **climbs in real time while users edit**. - It does **not** drop when a user leaves the workspace, and it **refills within seconds after the y-websocket server restarts** — because the leaked providers are detached, self-reconnecting objects living in open browser tabs. The y-websocket server itself is not resource-constrained — this is a client-side connection leak, not a server capacity problem. **Root cause — two distinct leaks, both on the `SharedModel` → `WebsocketProvider` code path:** **Leak B (dominant, per-edit).** `WorkflowCompilingService` runs a compile-on-edit subscription that, on *every* operator/link/property edit, builds a throwaway `WorkflowGraph` for validation (`ValidationWorkflowService.getValidTexeraGraph()`). `WorkflowGraph`'s constructor **unconditionally** creates a `SharedModel`, which **unconditionally** opens a new `/rtc` WebSocket (auto-connecting, random room). The throwaway graph is read once (by `ExecuteWorkflowService.getLogicalPlanRequest`) and **never destroyed** → a brand-new WebSocket leaks on every edit and reconnects forever. A user building a 20-operator workflow generates dozens of edits → dozens of permanent sockets. This drives the disproportionate per-user count and the real-time climb. **Leak A (secondary, per-navigation).** `SharedModel.destroy()` calls `wsProvider.disconnect()` (and only when currently connected) instead of `wsProvider.destroy()`. In `[email protected]`, `disconnect()` does **not** clear the provider's internal reconnect timer (`_checkInterval`), so the provider is never garbage-collected and — if it wasn't OPEN at destroy time (e.g. mid-reconnect during a workflow switch) — keeps reconnecting → a zombie socket per workflow switch/navigation. Relevant source (all under `frontend/src/app/workspace/service/`): - `workflow-graph/model/shared-model.ts` — the only `new WebsocketProvider` construction site; buggy `destroy()`. - `workflow-graph/model/workflow-graph.ts` — constructor unconditionally does `new SharedModel()`. - `validation/validation-workflow.service.ts` — `getValidTexeraGraph()` builds the throwaway graph per edit. - `compile-workflow/workflow-compiling.service.ts` — the compile-on-edit subscription that drives it. **Expected:** Opening a workflow should establish exactly **one** `/rtc` WebSocket. Editing (add/delete operators, edit properties, add/remove links) should not open any additional sockets. Switching or closing a workflow should tear the socket down cleanly (no lingering/reconnecting sockets). ### How to reproduce? Client-side (browser DevTools → Network → **WS** filter): 1. Open a workflow. Observe **one** `/rtc` WebSocket. 2. Add/delete operators, edit operator properties, add/remove links repeatedly. **Observed:** a new `/rtc` WS appears on each edit and stays open (and keeps reconnecting), instead of the count staying at one. 3. Switch workflow A → B, or navigate away / close the tab. **Observed:** old `/rtc` sockets linger and reconnect instead of closing. The same leak can be observed server-side by counting established connections to the y-websocket server while a single user edits a workflow: the count climbs steadily with each edit and never falls, even though only one browser tab is open. ### Version/Branch 1.3.0-incubating-SNAPSHOT (main) ### Commit Hash (Optional) _Both leaks are present in current `main` and reproduce with `[email protected]` / `[email protected]`._ ### What browsers are you seeing the problem on? Chrome ### 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]
