[shayansadeghieh]

TL;DR

The existing node-expansion timing can make an expansion look fast while its child data is still loading. In a completed synthetic workflow, flyteconsole.node.expand recorded 38.1 ms, while the new readiness measurement for the same click recorded 5,893 ms. Another expansion recorded 152.2 ms versus 5,972.7 ms.

We need to track this loading gap to evaluate future performance improvements. Add flyteconsole.node.expand.children_loaded, measured from the expand click until the expanded rows satisfy their child-loading readiness checks. Keep the existing row-commit measurement and add workflowName to both. This PR adds telemetry; it does not optimize the underlying loading path.

Type

• Feature

Are all requirements met?

• Code completed
• Browser smoke tested
• Unit tests added
• Code documentation added

Observed loading gap

Manually expanded six nested levels of the same completed synthetic execution, one at a time, in a local production build served through Podman and connected to the backend. Both measures completed at every tested level. These are observations from one sequence, not averages; both columns start at the same click.

Expansion	Rows committed: node.expand	Child readiness: node.expand.children_loaded
Root	13.7 ms	1,023.5 ms
Nested level 1	21.6 ms	713.2 ms
Nested level 2	23.5 ms	1,206.6 ms
Nested level 3	38.1 ms	5,893.0 ms
Nested level 4	152.2 ms	5,972.7 ms
Nested level 5	224.4 ms	224.4 ms

The deeper expansions expose roughly six seconds of loading that the original measurement does not capture. These timings include fetching and frontend processing through the readiness checks; they do not isolate the cause of the delay or measure the final browser paint. Equal timings at the last level mean readiness was already satisfied when the row-commit measurement was recorded.

Synthetic workload

• 3,871 generated execution nodes, excluding system start/end nodes: 400 dynamic parents, 399 collector tasks, and 3,072 leaf tasks.
• Six dynamic levels, using fanout [1, 1, 12, 32] and eight leaf tasks per deepest parent.
• Each configuration contains 2,048 synthetic string fields with 64-byte values: 128 KiB of value data, or 247,809 bytes (~242 KiB) as compact JSON including field names.
• The concrete configuration is embedded into each generated branch/leaf node's input bindings. This deliberately exercises large dynamic workflow definitions and repeated configuration data. Tasks produce small integer outputs; measurements were taken after the execution had completed.

Separately fetched node-data responses for that same expanded path had the following JSON body sizes:

Expanded parent	Generated children in its definition, excluding start/end	Node-data response body
Nested level 3	12 dynamic children + 1 collector	4,765,167 bytes (4.54 MiB)
Nested level 4	32 dynamic children + 1 collector	12,046,907 bytes (11.49 MiB)
Nested level 5	8 leaf tasks + 1 collector	3,303,550 bytes (3.15 MiB)

These are uncompressed JSON response-body sizes, including the compiled dynamic workflow and execution data. They are not compressed transfer sizes or total bytes downloaded during each expansion.

Implementation

1. NodeExecutionsTable saves the click time and records the existing measurement when expanded rows commit.
2. Each NodeExecutionDynamicProvider reports readiness. Parent rows wait for successful child responses to reach the shared execution-data map; dynamic nodes also wait for their downloaded workflow definition to be applied to the row's graph data. Leaf rows have no child-loading requirements.
3. The table records the new measurement when the clicked parent and its displayed descendants all report ready, using the original click time.

Rows confirmed to be outside the viewport do not block completion because their requests are driven by visibility. Cached data and successful empty responses count as ready; background polling does not extend the measurement. Failed requests stay pending so a successful retry includes the wait. Collapse, navigation, changed filters, or another toggle cancels the pending timing. Only the latest expansion is tracked.

See docs/node-loading-telemetry.md for the flow and how to inspect the browser entries.

Validation and telemetry overhead

• 25 tests passed across five suites, including readiness, retries, cancellation, nested expansions, and avoiding table renders for idle readiness reports.
• Built both master (6afaddd) and this branch (3044b63) as local production Podman images and manually exercised the same six-level expansion path on the same completed synthetic execution. Inspected flyteconsole.node.expand measurements on both builds; both showed increasing row-commit latency at deeper levels. On this branch, also verified that children_loaded completed at all six tested levels, producing the measurement pairs above.
• Readiness reports update a ref-backed Map in place. Reports received without an active expansion do not request a table render. An isolated local Node benchmark measured a median of 0.16 ms for 3,000 map updates across three runs. This measures map bookkeeping only, excluding React, browser rendering, and network work.