feat(frontend): capture per-operator performance metrics

[PG1204]

What changes were proposed in this PR?

Foundation for the workflow runtime performance heat-map (umbrella #5772).
This PR captures all per-operator execution metrics as ground truth, with no UI change.

The backend streams 11 statistics per operator, but the frontend OperatorStatistics type only declared 6, the timing and byte-size fields arrived over the websocket andwere silently dropped. This PR:

• Extends OperatorStatistics with the 5 missing optional fields (input/output size, data/control processing time, idle time); they deserialize straight from the existing websocket payload, so no backend or websocket change is needed.
• Adds a pure helper performance-metrics.ts: an OperatorPerformanceMetrics model, a HeatmapView enum, toPerformanceMetrics, rawMetricForView (bottleneck-oriented per-view cost), and normalizeScores (log1p + min-max into [0,1]).
• Extends WorkflowStatusService with a derived, BehaviorSubject-backed performance-metrics stream (getPerformanceMetricsStream / getCurrentPerformanceMetrics) and a setExternalStatus ingestion point for later restoring historical stats. The existing status pass-through API is unchanged.

All values arriving over the wire are coerced to finite, non-negative numbers, so missing / NaN / Infinity / negative inputs cannot leak into the scoring math.

Any related issues, documentation, discussions?

Closes #5773. Part of umbrella #5772. Follows RFC discussion #5216.

How was this PR tested?

New Vitest specs, run with:
cd frontend && ng test --watch=false --include "/performance-metrics.spec.ts" --include "/workflow-status.service.spec.ts"

• performance-metrics.spec.ts (19 tests): field mapping, missing/zero/NaN/Infinity defaults, per-view formulas, and normalizeScores edge cases (empty, single, all-equal, heavy-tail, unicode ids).
• workflow-status.service.spec.ts (8 tests, new, the service had none): event forwarding, ignoring other event types, derived-metrics emission, setExternalStatus, reset/clear.

Also verified: tsc --noEmit (strict) clean, eslint ./src clean, Prettier clean, and the existing WorkflowStatusService consumer specs still pass (67 tests).

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

This PR was co-authored by Claude Opus 4.7, in compliance with ASF.

[PG1204]

/request-review @Yicong-Huang

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 53.88%. Comparing base (e270f83) to head (67e81f1).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5834      +/-   ##
============================================
- Coverage     54.39%   53.88%   -0.51%     
+ Complexity     2859     2722     -137     
============================================
  Files          1107     1104       -3     
  Lines         42767    42641     -126     
  Branches       4599     4591       -8     
============================================
- Hits          23263    22978     -285     
- Misses        18152    18328     +176     
+ Partials       1352     1335      -17     

Flag	Coverage Δ		*Carryforward flag
access-control-service	70.44% <ø> (ø)		Carriedforward from e3df0ce
agent-service	34.36% <ø> (ø)		Carriedforward from e3df0ce
amber	55.05% <ø> (-1.13%)	⬇️	Carriedforward from e3df0ce
computing-unit-managing-service	1.65% <ø> (ø)		Carriedforward from e3df0ce
config-service	56.06% <ø> (-1.30%)	⬇️	Carriedforward from e3df0ce
file-service	57.36% <ø> (-1.24%)	⬇️	Carriedforward from e3df0ce
frontend	48.31% <100.00%> (+<0.01%)	⬆️
pyamber	90.09% <ø> (-0.11%)	⬇️	Carriedforward from e3df0ce
python	90.76% <ø> (ø)		Carriedforward from e3df0ce
workflow-compiling-service	58.69% <ø> (ø)		Carriedforward from e3df0ce

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

☔ View full report in Codecov by Harness.
📢 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]

@Yicong-Huang This PR introduces performance as a cleanly separated concept on WorkflowStatusService. As per your point in #5216 about separating state vs statistics as sub-concepts, I kept that out of this PR to avoid adding unused API, since nothing consumes a standalone state stream yet. Happy to do that separation here or as a follow-up, which would you prefer?

[Yicong-Huang]

@PG1204 this sounds like a feature? if so please update title and description.

[Copilot]

Pull request overview

This PR lays the frontend data foundation for a future workflow runtime performance heat-map by typing all per-operator metrics already sent over the websocket and deriving a normalized, overlay-ready performance model in WorkflowStatusService (no UI changes).

Changes:

• Extend OperatorStatistics with the missing optional timing and byte-size fields so they deserialize from the existing websocket payload.
• Add a framework-free performance-metrics.ts helper (model + view selector + normalization utilities).
• Enhance WorkflowStatusService to publish a derived performance-metrics stream (BehaviorSubject-backed) and accept externally-provided status snapshots; add new Vitest coverage for both the helper and service.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/src/app/workspace/types/execute-workflow.interface.ts	Adds missing optional per-operator timing/size fields to match websocket payload.
frontend/src/app/workspace/service/workflow-status/workflow-status.service.ts	Derives and exposes per-operator performance metrics from status updates; adds external ingestion path.
frontend/src/app/workspace/service/workflow-status/workflow-status.service.spec.ts	New unit tests for status forwarding and derived performance metrics behavior.
frontend/src/app/workspace/service/workflow-status/performance-metrics.ts	New pure helper for mapping, view-specific raw metrics, and normalization into [0,1].
frontend/src/app/workspace/service/workflow-status/performance-metrics.spec.ts	New unit tests covering mapping, per-view formulas, and normalization edge cases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Yicong-Huang]

I think throughput is calculated wrongly.

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @jaeyun0503, @aglinxinyuan
  You can notify them by mentioning @jaeyun0503, @aglinxinyuan in a comment.

[PG1204]

@Yicong-Huang This PR introduces performance as a cleanly separated concept on WorkflowStatusService. As per your point in #5216 about separating state vs statistics as sub-concepts, I kept that out of this PR to avoid adding unused API, since nothing consumes a standalone state stream yet. Happy to do that separation here or as a follow-up, which would you prefer?

@Yicong-Huang i feel a separate PR would be better, would appreciate your input as well on this

[Yicong-Huang]

@Yicong-Huang i feel a separate PR would be better, would appreciate your input as well on this

yeah let's do it separately.