fix(frontend): preserve operator state border on workflow page return

[PG1204]

What changes were proposed in this PR?

Fixes a visual regression where an operator's border, state text, port row counts, and worker count reset to default after navigating away from a workflow page and returning, even though the execution state is still cached in WorkflowStatusService.

Root cause: WorkspaceComponent clears the workflow on destroy and calls reloadWorkflow() on re-init, recreating every operator from the workflow JSON with default JointJS attributes. The cached execution status was never reapplied, and the validation pass that runs on operator-add called changeOperatorColor(..., true) for valid operators, overwriting rect.body/stroke and forcing the border back to gray.

Fix (two changes, both in workflow-editor.component.ts):

Subscribe to getOperatorAddStream() inside handleOperatorStatisticsUpdate. When an operator is added (drag-drop, reloadWorkflow, undo/redo, collaborative add via Yjs - all routed through a single emission point), look up the cached OperatorStatistics. If present, call changeOperatorStatistics(...) to restore the state color, port labels, worker count, and state text. New operators with no cached entry early-return and get default coloring.

Make handleOperatorValidation status-aware. Invalid operators still get a red border (priority preserved). For valid operators, the handler now checks the cached status - if one exists, it repaints via changeOperatorState(...) instead of overwriting with default gray. Valid operators with no cached status continue to get the default gray border.

Before fix:

473837274-d703b42e-8504-4735-bc9a-bcac9602c201.mov

After fix:

Screen.Recording.2026-05-22.at.4.18.14.PM.mov

Any related issues, documentation, discussions?

Fixes #3614.

How was this PR tested?

Unit tests: Three tests added to workflow-editor.component.spec.ts under a new describe("operator border restoration after navigation") block:

Valid operator + cached Completed -> changeOperatorState(..., Completed) is called.
Valid operator + empty cache -> default changeOperatorColor(..., true) is called (existing behavior preserved).
Invalid operator + cached Completed -> changeOperatorColor(..., false) is called, red wins (existing behavior preserved).
All three pass under Vitest (ng test).

Manual UI testing: Reproduced the issue's recording locally:

Open a workflow (e.g., CSV File Scan → Radar Chart) and run it; both operators turn green with port row counts.
Navigate to a different page, then back.
Before fix: operators reset to default gray borders, row counts blank. After fix: green borders, row counts, worker counts, and "Completed" state label all persist.
Edge cases manually verified: fresh workflow (default coloring), new operator dragged in after a completed run (default for new, cached for existing), re-running (resetStatus repaints Uninitialized, live updates flow normally), invalid operator with cached Completed (red border, validation priority).

Note: workflow-editor.component.spec.ts was previously excluded from the default jsdom test target in angular.json. This PR removes that exclusion (so the new tests run in CI and contribute to Codecov coverage) and comments out six pre-existing mouse-event tests that fail under jsdom (they continue to pass in the ng run gui:test-browser target, marked with TODO(#3614) in place). A follow-up PR will revive those commented-out tests.

Was this PR authored or co-authored using generative AI tooling?

Co-authored-by: Claude Code (Anthropic Claude Opus 4.7)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.89%. Comparing base (223a27b) to head (ca3d61c).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5146      +/-   ##
============================================
+ Coverage     50.29%   50.89%   +0.59%     
+ Complexity     2417     2378      -39     
============================================
  Files          1054     1053       -1     
  Lines         40905    40501     -404     
  Branches       4378     4314      -64     
============================================
+ Hits          20575    20612      +37     
+ Misses        19100    18700     -400     
+ Partials       1230     1189      -41     

Flag	Coverage Δ		*Carryforward flag
access-control-service	39.41% <ø> (-2.49%)	⬇️	Carriedforward from 7bd6550
agent-service	33.76% <ø> (ø)		Carriedforward from 7bd6550
amber	51.58% <ø> (-0.41%)	⬇️	Carriedforward from 7bd6550
computing-unit-managing-service	0.00% <ø> (-1.39%)	⬇️	Carriedforward from 7bd6550
config-service	0.00% <ø> (-54.69%)	⬇️	Carriedforward from 7bd6550
file-service	37.99% <ø> (-0.43%)	⬇️	Carriedforward from 7bd6550
frontend	45.39% <100.00%> (+2.07%)	⬆️
pyamber	?
python	90.79% <ø> (-0.02%)	⬇️	Carriedforward from 7bd6550
workflow-compiling-service	57.25% <ø> (-1.15%)	⬇️	Carriedforward from 7bd6550

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[PG1204]

Codecov flagged 0% patch because my tests are in workflow-editor.component.spec.ts, which is excluded from the unit-test runner in angular.json. I'm planning to move them into a new sibling file workflow-editor-status-restoration.spec.ts so the default glob picks them up and was verified locally that this brings patch coverage close to 100%. Happy to take a different approach if the team prefers, otherwise can push the new planned spec.ts file.

[Yicong-Huang]

For UI/user facing changes, please include before and after screenshots in the PR description, under What changes were proposed in this PR? part. so that reviewer can easily understand the change. Thanks.

[Yicong-Huang]

Also please add tests to cover your changes.

[PG1204]

@Yicong-Huang I have added a comment above regarding the test file & code coverage.

[Yicong-Huang]

@Yicong-Huang I have added a comment above regarding the test file & code coverage.

just saw it, sorry. sg, you can place the tests else where for now, or simply add the tests in the same file and comment out the previous tests.

[PG1204]

@Yicong-Huang I have added a comment above regarding the test file & code coverage.

just saw it, sorry. sg, you can place the tests else where for now, or simply add the tests in the same file and comment out the previous tests.

No worries. Thanks for the suggestions.

[PG1204]

@Yicong-Huang I have added a comment above regarding the test file & code coverage.

just saw it, sorry. sg, you can place the tests else where for now, or simply add the tests in the same file and comment out the previous tests.

Quick clarification on Option 2, since workflow-editor.component.spec.ts is currently in angular.json's exclude list, commenting out the previous tests by itself wouldn't make the file run in CI (so Codecov would still report 0% on the new tests). Were you implicitly suggesting I also remove the exclusion as part of this, or would you prefer that change be left out of this PR?

[Yicong-Huang]

you can

• move out workflow-editor.component.spec.ts from exclusion list,
• add your new tests there while keeping other tests still commented.

Alternatively you can use another PR to enable this workflow-editor.component.spec.ts and uncomment and fix the previous test cases first.

[PG1204]

you can

• move out workflow-editor.component.spec.ts from exclusion list,
• add your new tests there while keeping other tests still commented.

Alternatively you can use another PR to enable this workflow-editor.component.spec.ts and uncomment and fix the previous test cases first.

Should I wait for this PR to be reviewed and merged first before raising the follow-up PR to uncomment (and fix) the test cases in workflow-editor.component.spec.ts?

[PG1204]

you can

• move out workflow-editor.component.spec.ts from exclusion list,
• add your new tests there while keeping other tests still commented.

Alternatively you can use another PR to enable this workflow-editor.component.spec.ts and uncomment and fix the previous test cases first.

Should I wait for this PR to be reviewed and merged first before raising the follow-up PR to uncomment (and fix) the test cases in workflow-editor.component.spec.ts?

/request-review @Yicong-Huang

I shall raise the follow-up PR as soon as this is merged. Thanks.

[chenlica]

I added @Xiao-zhen-Liu to be a reviewer, assuming @Yicong-Huang may not be very available.

My preference is that if the test cases are not related to this functionality of this PR, it should be fixed in a separate PR.

[Yicong-Huang]

as we are low on coverage, I would encourage to add test cases to related files when fit, even it is not fully related to the changed line. Otherwise we won't know if the change in this PR would break some related parts (because we don't have tests for them).

After we have reached to a good ratio of coverage, then we can make it strict that only introduce or change tests related to the changed lines.

[Xiao-zhen-Liu]

Thanks for tackling #3614 — the writeup of what was going wrong is excellent, and the actual fix (the two changes in workflow-editor.component.ts) is small, focused, and fixes a real problem. Two things worth addressing, both about how the border color is decided and how the new tests check it.

How the border color gets decided

• The underlying problem is that two separate parts of the code both set the operator's border color, and they were overwriting each other. This fix makes them agree in the normal case (a valid operator with a saved "completed" status), which is correct. But they are still two separate parts setting the same color, with the same look-up-and-repaint logic duplicated in both, and one tricky case remains: an operator that is both invalid AND has a saved "completed" status. Red (invalid) is supposed to win, but whether it actually does depends on which of the two code paths runs last — and nothing guarantees that order. It works today, but it's fragile. Having a single place decide the final color (check validity first, then saved status, then fall back to the default) would make this reliable and remove the duplicated logic that now lives in both places.

The new tests

• The new tests check "was a particular paint function called?" rather than "what color did the operator actually end up?". Because the same paint function is also called from the other new code path, one of the tests would pass even if the fix were removed, and another doesn't confirm the final color actually wins. Checking the operator's final border color directly would make the tests genuinely verify the behavior. See the inline notes on the two tests.

[Xiao-zhen-Liu]

Requesting changes — I think two of the points raised are worth addressing before merge rather than leaving as follow-ups:

1. Decide the operator's border color in one place. Right now two separate parts of the code set it, with the same look-up-and-repaint logic duplicated in both. Consolidating it into a single decision (check validity first, then saved status, then the default) removes the duplication and also fixes the edge case where an operator that is both invalid and has a saved "completed" status can show the wrong color depending on which code path happens to run last.

2. Make the two new tests check the operator's final border color rather than just whether a paint function was called. As written, one of them would pass even if the fix were removed, so the regression tests don't yet guard against the regression.

Details are in the inline comments. The behavior fix itself is correct and close — these are about making it robust and properly tested.

[PG1204]

Requesting changes — I think two of the points raised are worth addressing before merge rather than leaving as follow-ups:

1. Decide the operator's border color in one place. Right now two separate parts of the code set it, with the same look-up-and-repaint logic duplicated in both. Consolidating it into a single decision (check validity first, then saved status, then the default) removes the duplication and also fixes the edge case where an operator that is both invalid and has a saved "completed" status can show the wrong color depending on which code path happens to run last.
2. Make the two new tests check the operator's final border color rather than just whether a paint function was called. As written, one of them would pass even if the fix were removed, so the regression tests don't yet guard against the regression.

Details are in the inline comments. The behavior fix itself is correct and close — these are about making it robust and properly tested.

@Xiao-zhen-Liu
Both points addressed in the latest push.

Extracted applyOperatorBorder(operatorID) as the single decision point, validity -> cached execution status -> default valid. Both handleOperatorValidation and the operator-add subscription delegate to it. The invalid + cached Completed case is now resolved structurally (the helper picks red unconditionally for invalid), so the outcome no longer depends on which stream fires last.
Rewrote the three existing tests to assert the actual rect.body/stroke on the paper ("green" / "#CFCFCF" / "red"). Added a 4th test specifically for invalid + cached Completed.

[PG1204]

you can

• move out workflow-editor.component.spec.ts from exclusion list,
• add your new tests there while keeping other tests still commented.

Alternatively you can use another PR to enable this workflow-editor.component.spec.ts and uncomment and fix the previous test cases first.

@Xiao-zhen-Liu
Quick question on the follow-up PR before I start on it, the 6 currently-commented-out mouse-event tests in workflow-editor.component.spec.ts fail under jsdom but pass under the new test-browser target. Given that main now has the *.browser.spec.ts convention (jsdom skips them, real Chrome runs them), my plan for the follow-up is to:

Move the 6 mouse-event tests into a new sibling file workflow-editor.browser.spec.ts (uncommented), with its own TestBed setup.
Remove the commented-out blocks and the orphan imports they leave behind from workflow-editor.component.spec.ts.
No angular.json changes, the new file is picked up by test-browser and skipped by test automatically thanks to the .browser.spec.ts glob.
Does that approach sound right, or would you prefer something different (e.g. polyfilling the jsdom gaps to keep everything in one file, or some other split)?

[Xiao-zhen-Liu]

you can

• move out workflow-editor.component.spec.ts from exclusion list,
• add your new tests there while keeping other tests still commented.

Alternatively you can use another PR to enable this workflow-editor.component.spec.ts and uncomment and fix the previous test cases first.

@Xiao-zhen-Liu Quick question on the follow-up PR before I start on it, the 6 currently-commented-out mouse-event tests in workflow-editor.component.spec.ts fail under jsdom but pass under the new test-browser target. Given that main now has the *.browser.spec.ts convention (jsdom skips them, real Chrome runs them), my plan for the follow-up is to:

Move the 6 mouse-event tests into a new sibling file workflow-editor.browser.spec.ts (uncommented), with its own TestBed setup. Remove the commented-out blocks and the orphan imports they leave behind from workflow-editor.component.spec.ts. No angular.json changes, the new file is picked up by test-browser and skipped by test automatically thanks to the .browser.spec.ts glob. Does that approach sound right, or would you prefer something different (e.g. polyfilling the jsdom gaps to keep everything in one file, or some other split)?

Can you move this discussion as a new issue if it is not going to be part of this PR?

[Xiao-zhen-Liu]

LGTM — both points addressed: border color is now decided in one place (applyOperatorBorder), and the tests assert the final border color. Nice work.

Optional, non-blocking: applyOperatorBorder re-runs validateOperator instead of reusing the validation stream's result — negligible, fine to leave or tidy later.

[PG1204]

you can

• move out workflow-editor.component.spec.ts from exclusion list,
• add your new tests there while keeping other tests still commented.

Alternatively you can use another PR to enable this workflow-editor.component.spec.ts and uncomment and fix the previous test cases first.

@Xiao-zhen-Liu Quick question on the follow-up PR before I start on it, the 6 currently-commented-out mouse-event tests in workflow-editor.component.spec.ts fail under jsdom but pass under the new test-browser target. Given that main now has the *.browser.spec.ts convention (jsdom skips them, real Chrome runs them), my plan for the follow-up is to:
Move the 6 mouse-event tests into a new sibling file workflow-editor.browser.spec.ts (uncommented), with its own TestBed setup. Remove the commented-out blocks and the orphan imports they leave behind from workflow-editor.component.spec.ts. No angular.json changes, the new file is picked up by test-browser and skipped by test automatically thanks to the .browser.spec.ts glob. Does that approach sound right, or would you prefer something different (e.g. polyfilling the jsdom gaps to keep everything in one file, or some other split)?

Can you move this discussion as a new issue if it is not going to be part of this PR?

Filed as #5318. Requesting your input on the same. Accordingly I shall raise the PR.