Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#8,580 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@yangzhang75 ya está trabajando en esto.

Desde el 19/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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
Lenguaje dominante
Scala
Estrellas
322
Forks
195
Merge medio
2 d 19 h
PR fusionados (30 d)
146

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/texera

Todos los issues de apache/texera

Issues similares

Más issues de Scala

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.