yangzhang75 opened a new pull request, #9021: URL: https://github.com/apache/texera/pull/9021
### What changes were proposed in this PR? Closes #8759. Part of the Form View feature (#8011); from the #8439 refinements (the result-frame item, raised in the #8441 review and deferred there). Two things about the chart frame a result card shows, neither of which a reader can see today. The issue reads as a visible fault -- a chart recreated on every emission, flickering through a run -- and that is not what happens: it was written from the code, and the code cannot do it. What is really there is a latent ordering bug and a piece of machinery that never fires. **The frame audited before it filtered.** `VisualizationFrameContentComponent` redraws on the result-update stream, throttled with `auditTime`, and the filter for its own operator ran after the audit. An update event carries only the operators whose result changed, so a window that closed on another operator's event handed the filter that event, which dropped it -- and this operator's pending redraw went with it. The last update of a run could leave the previous picture showing for good. The filter now runs first, so only this operator's updates enter the audit and what comes out is the redraw it was waiting on. The canvas result panel mounts the same component and gains the same reliability. **The Form View keyed each chart frame on a per-operator version**, bumped on every result update, so that a changed result would rebuild the frame rather than reuse it (the frame reads its content once, at creation). It could not do that. Every visualisation operator takes its whole input before it draws (`process_table`, single-snapshot output ports), so the update that carries a picture is the same one that mounts the frame, and a second one never arrives. A re-run does not need the key either: it replaces the snapshot inside the operator's result service, which lives until the page is left, and a result that is cleared takes the frame down through `vizHasContent`. The key, the map behind it and the `*ngFor` that carried it go. So: no visible change. A latent correctness fix, and the removal of code that cannot run. ### Any related issues, documentation, discussions? Closes #8759, which came out of the #8441 review (where the key was introduced, with the Copilot threads about it left open for this fix). Part of #8439 and the Form View feature #8011. The issue's "expected" -- bump the key only for a genuinely new result, and handle `clearResults` -- is not what this does, because measuring showed there is nothing for a key to do. `clearResults()` runs when a workspace is torn down and when a computing unit is switched, not during a run. Worth knowing, not changed here: the backend emits an update only for an operator whose tuple count changed, so a single-row visualiser that replaces its HTML at the same count produces no event at all, on the canvas and the form alike. That is a separate gap and a follow-up candidate. ### How was this PR tested? Unit tests (vitest). The frame's spec: a redraw pending for this operator survives a later emission for another operator -- this operator's update, half the window, another operator's event, the rest of the window, and the picture that lands is this operator's new one -- which is the case the old order lost; the existing redraw-after-the-window and ignore-other-operators tests still pass. The form's spec: a result update re-limits the shown results and re-fits the visualisations and rebuilds nothing, and the test that pinned the removed key is gone with it. By hand, on two dev builds of the same base commit, one with this change and one without: a slow Python UDF source (40 rows, one every 0.4 s, batch size 1) feeding a pie chart, both results shown on the Form View. Counted off the websocket, the chart's operator receives two result updates per run and only the last carries a picture; counted in the DOM, the chart component is mounted exactly once per run -- on both builds, and twice over two runs on both builds. That measurement is why the key is described above as machinery that never fires, and why this PR has no before/after recording: there is nothing on screen to tell the two builds apart. Each guard was deletion-checked and turned a named test red (the audit/filter order; the redraw itself). eslint, prettier and the production (AOT) build pass; the full frontend suite passes. ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (Anthropic). Co-authored with Claude, reviewed line by line by the author before submission. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01FVvP3ttj22f9LB4p9u2anY -- 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]
