[antiguru]

8 of 14 in the interactive-runtime stack. Stacks on #38390, followed by #40558. Tracked by CPU-216. The design document is doc/developer/design/20261107_interactive_runtime.md in #40559.

With --interactive-compute-timely-config, clusterd runs two compute runtimes in one process: the first takes Maintenance, the second Interactive, and worker i of each takes the same per-worker sharing registry. clusterd asserts that both run the same worker layout. A Multiplexer fronts both on the one controller endpoint. Without the flag the process runs a single Solo runtime, unchanged.

• Placement names the dataflow classes a runtime renders, and handle_create_dataflow checks it first. A dataflow the runtime does not render only records its exports as peers, with a peer bundle in traces for each index on the interactive runtime. Peers never enter collections, so only the runtime that renders a collection reports its frontiers. Schedule and AllowWrites are no-ops on a peer, AllowCompaction moves its hold, and the empty frontier removes it. Logging indexes are peers too, at the minimum time.
• An index peek on the interactive runtime reads compute_state.traces like on any runtime. A peek whose index has not sealed its timestamp waits in queued_peeks. A peek naming an index neither hosted nor held as a peer is answered with an error.
• ProcessGlobals applies the process-wide settings from the maintenance runtime only. process_globals.rs documents the window on a process's first connection in which the interactive runtime runs with the previous values.

Not in this PR: the reconcile barrier, which #40558 adds. Until then, two runtimes reconciling a connection that recreates an index at the same as_of can bind the new peer to the old incarnation's slot. The flag being off keeps that unreachable.

enable_compute_interactive_runtime is replica-scoped and off. It is read when a replica is provisioned, so it is not a live toggle, and is resolved in environmentd, which decides the replica's ports. The flag is in UNINTERESTING_SYSTEM_PARAMETERS and pinned to FALSE in parallel-workload's FlipFlagsAction until #38393 turns it on in tests. enable_compute_interactive_dataflows, on by default and flipped by FlipFlagsAction, keeps peek dataflows on the maintenance runtime when off.

Tests in compute_state/tests.rs cover peeks over a peer bundle, peeks waiting for publication and for the seal, and a build over an unpublished peer index.

A reviewer should check the peer paths in handle_create_dataflow and handle_allow_compaction, and the split of ProcessGlobals.

Posted by Claude Code.

🤖 Generated with Claude Code

[linear-code]

CPU-215

[bosconi]

The two-runtime plumbing looks sound, but the interactive config derivation lost its tests and the resource accounting needs stating, details inline.

• Nothing in CI runs the two-runtime clusterd path until #38393 turns the flag on. Please add a Verification section to the description saying so, and land the stack together.

[bosconi]

Read the flag with ENABLE_COMPUTE_INTERACTIVE_RUNTIME.get_with_overrides(&self.dyncfg, overrides), the way ENABLE_UNIFIED_CLUSTER is read a few lines below (L719-L736). That drops the interactive_runtime parameter from create_replica, provision_replica and both adapter call sites, and removes CatalogState::replica_scoped with its string reparse.

[bosconi]

If the flag moves to get_with_overrides in provision_replica, this helper can go. If it stays, it needs tests over Catalog::with_debug: a stored "on" override returns true, and an unparsable override falls back to the environment value, not config.default().

[bosconi]

This derivation lost the prepare_interactive_compute_config unit tests from dca62ce. Dropping interactive.process = args.process or loosening the assert would now pass CI, and every process but ordinal 0 would join the interactive cluster as process 0. Please pull it back out as a free function next to multiplex_compute and restore the tests, including an equal-product, different-shape case (workers = 4 over 1 address vs workers = 2 over 2).

[bosconi]

The interactive runtime doubles the Timely worker threads under unchanged cpu_limit, memory_limit and zero_copy_limit, and with enable_worker_core_affinity both runtimes pin worker i to the same core. Please state the intended resource accounting in the description: should the interactive runtime get fewer workers, or should the allocation grow when the flag is on?

[bosconi]

nit: only Copy fields remain after the addresses override, so the base is never moved and the clone can go, as in the compute_timely_config construction above.

Suggested change

	..compute_proto_timely_config.clone()
	..compute_proto_timely_config

[bosconi]

is_some() holds for any config. Comparing the value also covers the serde round trip the flag depends on:

Suggested change

	assert!(args.interactive_compute_timely_config.is_some());
	assert_eq!(
	args.interactive_compute_timely_config,
	Some(timely_config(1, &["127.0.0.1:2103"]))
	);