Interface TelemetryRunViewsBatchParams

Internal marker for engine-initiated calls

Per-view keyset-pagination cursors (serialized AfterKey), parallel to Entities (one entry per view, same order). See StartRows.

Number of views in the batch

Entity names being queried in the batch, one entry per view. A view identified only by ViewEntity (no EntityName/ViewName/ViewID) is recorded as '' rather than dropped, so this array stays index-parallel to Filters/OrderBys/StartRows/ AfterKeys. The fingerprint skips falsy entries; display sites should too.

When true, every view in the batch opted out of optimization/redundancy analyzers.

Optional caller-provided justification for the exemption (first non-empty across the batch).

Per-view SQL WHERE clause filters, parallel to Entities (one entry per view, same order). Populated where the batch event is recorded so the fingerprint can distinguish two batches over the SAME entity set but with DIFFERENT filters (e.g. an expiry sweep vs. a decay sweep both over {AI Agent Notes, AI Agent Examples}). An entry may be undefined when a view supplied no filter.

Per-view SQL ORDER BY clauses, parallel to Entities (one entry per view, same order). See Filters for why per-view detail is needed at batch granularity.

Per-view offset-pagination cursors (StartRow), parallel to Entities (one entry per view, same order). Required for the same reason the single-RunView fingerprint carries StartRow: consecutive pages of a sweep differ ONLY in the cursor, so omitting it collapses every page onto one fingerprint and the Duplicate analyzer fires from page 2 onward. This matters for size-1 batches too — a server-side RunView with BypassCache or AfterKey is routed through RunViews([params]) (see ProviderBase.RunView), and on the client EVERY RunView takes that route.