Result table pages by the wrong row count for an operator with two outputs, such as Split #9050

What happened?

When an operator with two output ports, such as Split, is at the end of a workflow, the result panel shows the rows of its first output but pages them by the row count of its second output. The pager can stop before the last rows of the first output, or it can offer pages past its end that come up empty.

In the example below, Split sends 13 rows to its first output and 7 to its second. The panel shows the first output, and its statistics row says 13 values, but the pager offers only 2 pages of 5. Rows 14, 15 and 17 cannot be reached.

The cause is in ExecutionResultService.onResultUpdate. Both output ports of a terminal operator are stored, and the row counts are collected into a map keyed by operator, so the port read last replaces the other. The result panel and its page requests read the first port, but the count it pages by can be the second port's.

I expected the pager to count the rows of the output it shows.

How to reproduce?

1. Add a Python UDF source that yields 20 rows, with an integer column id from 0 to 19.
2. Connect it to a Split with Split Percentage 70, and leave both of Split's outputs unconnected.
3. Run the workflow. Split reports 13 rows on one output and 7 on the other.
4. Click Split and open the result panel. The statistics row says 13, but the pager has 2 pages, and page 2 ends at id 13.

Version/Branch

1.4.0-incubating-SNAPSHOT (main)

Commit Hash (Optional)

22b82a2

What browsers are you seeing the problem on?

Chrome

Relevant log output

No response