Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Switching between a workflow's canvas and Form View reloads the page and reconnects everything

Closed
  • Is something wrong?
#8,580 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@yangzhang75 is already working on this.

Since Sep 19, 2026.

Assessment

This issue has not been assessed yet.

Description

Task Summary

Switching between a workflow's two views -- the operator canvas (/user/workflow/:id) and the Form View (/user/workflow/:id/form) -- is a full browser page load in both directions (window.location.href in MenuComponent.openFormViewPage and WorkflowFormComponent.openCanvasPage). The two views are views of one open workflow, so everything that makes the workflow live is thrown away on the way out and rebuilt on the other side:

  • both ngOnDestroys call clearWorkflow() (which destroys the Yjs shared document and leaves its co-editing room), computingUnitStatusService.disconnect(), resetExecutionAndWorkers(), and clear the console and results;
  • the arriving view then re-bootstraps Angular (APP_INITIALIZER blocks on /api/config), re-parses the whole bundle, re-fetches operator metadata that a providedIn: "root" singleton had already cached for the page, fetches the workflow, opens a new shared document and room, reconnects the computing unit, and waits for the backend to report the execution state again.

The visible cost is seconds of blank page on every switch, and a run that was already going takes that long to say so again. Nothing about it is necessary: WorkflowWebsocketService, ComputingUnitStatusService, WorkflowActionService and the joint graph it owns are all root-provided and survive a route change.

Routing between the two was tried during the Form View work and reverted; the code comments record three symptoms, two of which have identified causes:

  1. A ghost coeditor of yourself. The arriving view built a second shared document for the same workflow, so the page joined the room it was already in and saw its own other client.
  2. Undraggable operators. A JointJS paper binds to the joint graph, which is root-provided and outlives the component that created it, and no paper is ever disposed -- neither WorkflowEditorComponent's nor MiniMapComponent's. Every mount left another paper listening to that graph from a detached DOM node, and whichever paper answered a pointer event decided whether an operator could be dragged. Harmless while every mount followed a page load.
  3. Broken runs. No independent cause found; likely a consequence of the first two, but this is the part that most needs checking in a browser.

Proposed: route in both directions, have the departing view hand the session to the arriving one instead of tearing it down, have the arriving view attach to what it was given instead of rebuilding it, and dispose both papers on destroy. Leaving the workspace altogether keeps today's teardown, including on unload.

Follow-up to the Form View feature (parent issue #8011); the switch itself landed in #8456.

Task Type
  • Performance
  • Refactor / Cleanup
Dominant language
Scala
Stars
316
Forks
192
Avg merge
4d 17h
Merged PRs (30d)
141

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/texera

All issues in apache/texera

Similar issues

More Scala issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.