Should a table with no rows keep its declared schema? #8735

Feature Summary

A port can finish having carried no rows, for example after a Filter that matches nothing. When that happens, a Python table operator gets a DataFrame with no columns at all. It does not get the port's declared columns with no rows under them. Table.from_tuple_likes reads the column names off the tuples, and there are none.

Any table operator that names one of its columns then raises KeyError. Sort is the plainest case. The visualization operators and any user-written UDFTableOperator hit it too.

To reproduce, build CSV File Scan, then a Filter no row satisfies, then Sort on a scanned column, and run it. Sort fails with KeyError naming the sort column, even though that column is on the link. Without the engine, Table(Table.from_tuple_likes([])) has columns: [], and sort_values(by=["x"]) on it raises KeyError: 'x'.

This was first filed as #8487. It was closed so it would not hold up unrelated work, and the question itself was left open. One view is that a table with no rows carries no schema by design. Another is that a table with no data can still be a real table, like a filter that matched nothing or a file with only a header, and its schema is information worth saving. This choice decides what every table operator sees on an empty input, so I'd like to hear from others before writing any code.

Proposed Solution or Design

Three options, none picked yet:

1. Keep today's behavior. A port with no rows reaches the operator with no columns, and an operator that names a column fails.
2. The engine skips process_table for a port with no rows and finishes it quietly.
3. The operator gets the port's declared columns with no rows under them. feat(python): give a port that carried no rows its declared columns #8488 did this and was closed.

Affected Area

Workflow Engine (Amber)