[kz930]

What changes were proposed in this PR?

The hover card gets a Pin button. Pinning turns it into a window beside the operator with the whole result table, tied to the operator by a dashed line. Several windows can be open at once; each can be dragged and resized, and follows its operator when it or the canvas moves.

An operator with more than one output gets a tab per output port in its window. The first port is the one the running execution reports on. Another port is read when its tab is shown, through the port-aware result service from #9054, and pages by the row count its replies carry. The execution reports a change only for the first port, so another port is read again as results arrive, at most once a second, and once more when the operator completes. If the chosen output is removed, the window shows the last one that is left. The table in a window fills the window: it measures the space its search bar, header, statistics row and pager take, and fits as many rows as are left. It shows its statistics row only when a column has statistics, which another port never has.

Any related issues, documentation, discussions?

Closes #9062. Part of #9052. Design discussed in #8842.

How was this PR tested?

A new spec for the pinned window covers its port tabs, the port it shows and the height it hands the table. New cases in the result table's spec cover filling a given height, the statistics row, and refreshing a port past the first. New cases in the editor's spec cover pinning, unpinning, unpinning a deleted operator's window, the window's position as the canvas moves, and the connector line on each side. The affected frontend specs pass. In the running app, a Split of 20 rows into 13 and 7 shows the first output's 13 rows in its first tab and the other 7 in its second, each paged correctly, and the pager ends near the window's bottom edge at any window size. A window pinned on a Split's second output during a run shows its rows when the run ends, and shows the new rows after a re-run.

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

Generated-by: Claude Code (Claude Opus 5.5)

🤖 Generated with Claude Code

[kz930]

@carloea2 could you take a look at this when you have a chance? It stays a draft until #9058 merges, but its own change, the last commit, is ready for review.

[github-actions]

Automated Reviewer Suggestions

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

• No candidates found from git blame history.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 77.58621% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.88%. Comparing base (312a0ce) to head (261c8eb).

Files with missing lines	Patch %	Lines
...ed-result-window/pinned-result-window.component.ts	55.10%	18 Missing and 4 partials ⚠️
...-result-window/pinned-result-window.component.html	62.06%	10 Missing and 1 partial ⚠️
...result-table-frame/result-table-frame.component.ts	90.32%	0 Missing and 3 partials ⚠️
...onent/workflow-editor/workflow-editor.component.ts	95.34%	0 Missing and 2 partials ⚠️
...ult-preview/operator-result-preview.component.html	83.33%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #9063      +/-   ##
============================================
+ Coverage     91.86%   91.88%   +0.02%     
+ Complexity     5022     4979      -43     
============================================
  Files          1277     1279       +2     
  Lines         56155    56138      -17     
  Branches       7310     7285      -25     
============================================
- Hits          51585    51581       -4     
- Misses         2740     2742       +2     
+ Partials       1830     1815      -15     

Flag	Coverage Δ		*Carryforward flag
access-control-service	77.44% <ø> (ø)		Carriedforward from f68ae31
agent-service	99.53% <ø> (ø)		Carriedforward from f68ae31
amber	86.06% <ø> (+0.14%)	⬆️	Carriedforward from f68ae31
computing-unit-managing-service	64.02% <ø> (ø)		Carriedforward from f68ae31
config-service	87.61% <ø> (ø)		Carriedforward from f68ae31
file-service	82.29% <ø> (ø)		Carriedforward from f68ae31
frontend	96.40% <77.58%> (-0.14%)	⬇️
notebook-migration-service	83.77% <ø> (ø)		Carriedforward from f68ae31
pyamber	98.46% <ø> (ø)		Carriedforward from f68ae31
workflow-compiling-service	77.95% <ø> (ø)		Carriedforward from f68ae31

*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.

[carloea2]

The pin-window changes pass 198 focused component tests and 63 tests in real Chromium, including the port tabs and result-table sizing. Focused prettier-eslint and ESLint checks pass. No blocker found in this increment after #9058. This does not approve the later removal of result access in #9060.

[github-actions]

⚠️ Benchmark changes need a look

🟢 4 better · 🔴 3 worse · ⚪ 8 noise (<±5%) · 0 without baseline

Compared against main 94914a0 benchmarked on this same runner, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.

Dashboard · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	378	0.231	26,071/33,964/33,964 us	🟢 -15.9% / 🔴 +177.8%
🟢	bs=100 sw=10 sl=64	833	0.508	118,244/141,446/141,446 us	🟢 -13.4% / 🔴 +62.3%
🔴	bs=1000 sw=10 sl=64	957	0.584	1,043,456/1,184,143/1,184,143 us	🔴 +5.4% / 🔴 +44.8%

Baseline details

Latest main 94914a0 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	378 tuples/sec	397 tuples/sec	1,019 tuples/sec	-4.8%	-62.9%
bs=10 sw=10 sl=64	MB/s	0.231 MB/s	0.242 MB/s	0.622 MB/s	-4.5%	-62.9%
bs=10 sw=10 sl=64	p50	26,071 us	22,978 us	10,144 us	+13.5%	+157.0%
bs=10 sw=10 sl=64	p95	33,964 us	40,389 us	12,225 us	-15.9%	+177.8%
bs=10 sw=10 sl=64	p99	33,964 us	40,389 us	15,527 us	-15.9%	+118.7%
bs=100 sw=10 sl=64	throughput	833 tuples/sec	839 tuples/sec	1,371 tuples/sec	-0.7%	-39.2%
bs=100 sw=10 sl=64	MB/s	0.508 MB/s	0.512 MB/s	0.837 MB/s	-0.8%	-39.3%
bs=100 sw=10 sl=64	p50	118,244 us	114,028 us	79,910 us	+3.7%	+48.0%
bs=100 sw=10 sl=64	p95	141,446 us	163,399 us	87,155 us	-13.4%	+62.3%
bs=100 sw=10 sl=64	p99	141,446 us	163,399 us	106,643 us	-13.4%	+32.6%
bs=1000 sw=10 sl=64	throughput	957 tuples/sec	951 tuples/sec	1,415 tuples/sec	+0.6%	-32.4%
bs=1000 sw=10 sl=64	MB/s	0.584 MB/s	0.581 MB/s	0.864 MB/s	+0.5%	-32.4%
bs=1000 sw=10 sl=64	p50	1,043,456 us	1,054,790 us	780,407 us	-1.1%	+33.7%
bs=1000 sw=10 sl=64	p95	1,184,143 us	1,123,975 us	817,814 us	+5.4%	+44.8%
bs=1000 sw=10 sl=64	p99	1,184,143 us	1,123,975 us	848,683 us	+5.4%	+39.5%

Raw CSV

config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,529.50,200,128000,378,0.231,26071.28,33963.51,33963.51
1,100,10,64,20,2401.84,2000,1280000,833,0.508,118243.77,141446.10,141446.10
2,1000,10,64,20,20909.23,20000,12800000,957,0.584,1043456.44,1184142.97,1184142.97

[aglinxinyuan]

Left some minor comments below.

[aglinxinyuan]

The port tabs and the fill-height table work nicely.

[carloea2]

Cell downloads still use the first output.

[kz930]

@carloea2 The cell download button is now hidden on outputs past the first, since the export reads port 0. Could you take another look?

[carloea2]

The cell download fix passes locally. With current main, 72 focused tests and 7163 full-suite tests pass, with one skipped. Please refresh main and rerun the failing macOS pinned-tab checks before marking it ready.