GeezerVison

Linked Issue

No issue yet. This adds the measurements for two planned issues: skip a run of a recursive sub-circuit that has no input, and let a sharded accumulator receiver finish its flush in the step in which its peers flush.

What this changes

A nested circuit runs to a fixed point once in every step of its parent, also when none of its imports has data. In transaction mode one commit takes several root steps, so a recursive view can run many times per commit with nothing to do. The circuit profile shows the steps and the runtime of a nested circuit, but not how many of its runs had input.

This PR adds three counters to each nested circuit node. They appear in the circuit profile, and so in support bundles:

How:

• ImportOperator::imported_empty() reports if the last imported value was empty. The default is None.
• Delta0 records val.is_zero(), and ImportAccumulator (the import of non_incremental circuits) records val.is_empty(), on each import. Delta0NonIterative keeps the default: it has no callers, and its D: Clone bound has no emptiness test.
• ChildNode::eval classifies each run after it runs the import nodes, and ChildNode::metadata reports the counts.
• profiler-lib takes the largest reading of the three counts (AggregationMode.Max), like steps_count, instead of adding them up over the workers.

The counters do not change what the circuit computes or when it runs.

A non_incremental circuit is also run once per parent step, but it only collects its input until the step in which the input is complete. The description of subcircuit_runs_count says so.

Describe Manual Test Plan

New tests in operator::dynamic::recursive::test::run_stats. Each builds a nested circuit over edges and, next to it, a chain of 8 joins over facts, so that a commit takes several root steps. Each measures root steps, inner steps (from scheduler events) and the new counters for each commit, with 1 and 4 workers. Run them with --nocapture to see the tables.

Results for recursion_runs_at_every_root_step with 4 workers (debug build), before and after merging main with 2fbe60d (#7745, a receiver finishes its flush in the step of the last flush):

With 1 worker, every commit took 1 root step and 1 run before and after. After the merge, a commit that does not touch the recursion's input still runs it once, with no input on any worker (#7744).

The test asserts today's behavior: the nested circuit runs once per root step. A change that skips runs without input must update the test.

Checks:

• I broke the counters on purpose in three ways (Delta0 always reports "empty"; the run count counts only runs with input; ImportAccumulator keeps the default). The tests failed each time.
• cargo test -p dbsp --lib -- recursive nonlinear_recursion profile delta0 non_incremental: 67 passed.
• profiler-lib: profile.test.ts passes (179 tests) under the Bun runtime. With the old profile.ts, the new mode(...) assertions fail. Under Node 20 the file does not load (entries().map needs iterator helpers); regionSize.test.ts and viewport.test.ts fail the same way with and without this change.
• cargo clippy -p dbsp --lib --tests -- -D warnings and cargo fmt: clean. The pre-commit hooks passed.

Checklist

• Unit tests added/updated
• Integration tests added/updated
• Documentation updated
• Changelog updated

Breaking Changes?

Mark if you think the answer is yes for any of these components:

• OpenAPI / REST HTTP API / feldera-types / manager (What is a breaking change?)
• Feldera SQL (Syntax, Semantics)
• feldera-sqllib (incl. dependencies fxp, etc.) (What is a breaking change?)
• Python SDK (What is a breaking change?)
• fda (CLI arguments)
• Adapters (including configuration)
• Storage Format / Checkpoints
• Others (specify)

Describe Incompatible Changes

None. The profile metric catalog gets three new entries.