feat(protocol): share evaluations across standing queries that differ only in bound constants, and cache their plans - #232

✅ No issues found.

• ⚠️ gui/lib/docs-bundle.ts - merge conflict rebasing onto origin/main

🔧 Fix applied.
✅ Re-checked - no issues remain.

• ⚠️ src/protocol/subscription/parameterized.rs:132 - Lifting turns every view's bound constants into free variables without checking whether the engine relied on those constants to limit work (Magic Sets on recursive relations, constant specialization, SIP). The cost guard (line 449) only reacts after a shared round has already run. A new family starts with sharing: AtomicBool::new(true) (line 531), and after every PROBE_AFTER=256 own evaluations record_own (line 480) turns sharing back on. Each of those rounds evaluates the unbound query, and every view in the family waits on it (line 574). Concrete case: two sessions subscribe to ?reach("a", Y) and ?reach("b", Y) over a large edge graph. Each own query is a Magic-Sets-restricted millisecond evaluation. The first shared round and then every 256th probe compute the full transitive closure, which can take seconds and a lot of memory, or get truncated at max_result_rows only after the full computation, before either delta is delivered. This conflicts with the intent's "Millisecond query and update latency must not regress" for bound recursive standing queries, which previously stayed restricted. Suggested fix: don't lift constants on atoms whose closure reaches a recursive relation (the family can check this against the snapshot's rules when it is formed or when the rules change), and/or bound how long a probe round may run relative to own_cost_us.
• ⚠️ src/protocol/subscription/parameterized.rs:449 - The sharing guard accepts a round costing up to max(2, bindings/2) times a view's own evaluation. With 200 bindings that is up to 100x own cost on a single evaluation that every view waits for. Without sharing, those 200 own evaluations run in parallel on compute_permits threads (ncpu minus a reserve), so the last delta lands after about 200own/P. When P > 2 (any machine with 4 or more cores reserves 2), the guard therefore accepts rounds whose latency is up to P/2 times worse than unshared re-evaluation, and the first views' deltas wait for the whole round instead of about one own evaluation. The baseline is also inflated: own_cost_us is updated only on own evaluations, and in practice the only one before sharing starts is each view's first evaluation, which includes the plan-cache miss compile (about 7 ms per the intent's data), so worth is overstated. The intent says latency must not regress. Whether to trade per-delta latency for server CPU this way is a policy choice: consider bounding a round by the unshared parallel latency (for example ownbindings/compute_permits) rather than by CPU saving, and excluding compile time from own_cost_us.
• ℹ️ src/protocol/subscription/parameterized.rs:535 - Families are keyed by (kg, lifted query text), but kinds are checked only after lookup (line 518). When ?a("x", X) and ?a(1, X) both lift to ?a(_L0, X), the second creates a new family and families.insert overwrites the live first family's entry. Every later subscriber of the first kind then fails the kinds check and starts yet another family, overwriting again. Results stay correct, but alternating kinds keep fragmenting families into single-binding ones that never share. Fix: put shape.kinds in the map key.

🔧 Fix applied.
5 issues (4 warnings, 1 info) still open:

• ⚠️ src/protocol/subscription/parameterized.rs:132 - Lifting turns every view's bound constants into free variables without checking whether the engine relied on those constants to limit work (Magic Sets on recursive relations, constant specialization, SIP). The cost guard (line 449) only reacts after a shared round has already run. A new family starts with sharing: AtomicBool::new(true) (line 531), and after every PROBE_AFTER=256 own evaluations record_own (line 480) turns sharing back on. Each of those rounds evaluates the unbound query, and every view in the family waits on it (line 574). Concrete case: two sessions subscribe to ?reach("a", Y) and ?reach("b", Y) over a large edge graph. Each own query is a Magic-Sets-restricted millisecond evaluation. The first shared round and then every 256th probe compute the full transitive closure, which can take seconds and a lot of memory, or get truncated at max_result_rows only after the full computation, before either delta is delivered. This conflicts with the intent's "Millisecond query and update latency must not regress" for bound recursive standing queries, which previously stayed restricted. Suggested fix: don't lift constants on atoms whose closure reaches a recursive relation (the family can check this against the snapshot's rules when it is formed or when the rules change), and/or bound how long a probe round may run relative to own_cost_us.
• ⚠️ src/protocol/subscription/parameterized.rs:449 - The sharing guard accepts a round costing up to max(2, bindings/2) times a view's own evaluation. With 200 bindings that is up to 100x own cost on a single evaluation that every view waits for. Without sharing, those 200 own evaluations run in parallel on compute_permits threads (ncpu minus a reserve), so the last delta lands after about 200own/P. When P > 2 (any machine with 4 or more cores reserves 2), the guard therefore accepts rounds whose latency is up to P/2 times worse than unshared re-evaluation, and the first views' deltas wait for the whole round instead of about one own evaluation. The baseline is also inflated: own_cost_us is updated only on own evaluations, and in practice the only one before sharing starts is each view's first evaluation, which includes the plan-cache miss compile (about 7 ms per the intent's data), so worth is overstated. The intent says latency must not regress. Whether to trade per-delta latency for server CPU this way is a policy choice: consider bounding a round by the unshared parallel latency (for example ownbindings/compute_permits) rather than by CPU saving, and excluding compile time from own_cost_us.
• ℹ️ src/protocol/subscription/parameterized.rs:535 - Families are keyed by (kg, lifted query text), but kinds are checked only after lookup (line 518). When ?a("x", X) and ?a(1, X) both lift to ?a(_L0, X), the second creates a new family and families.insert overwrites the live first family's entry. Every later subscriber of the first kind then fails the kinds check and starts yet another family, overwriting again. Results stay correct, but alternating kinds keep fragmenting families into single-binding ones that never share. Fix: put shape.kinds in the map key.
• ⚠️ src/protocol/subscription/parameterized.rs:513 - The re-probe after a family stops sharing still fires far too often for large families, so the latency regression from round 1's lifted-round-unbounded finding is still reachable. Round 1's fix only changed the initial state (sharing now starts false) and left this cadence alone. own_since_stop counts own evaluations summed over every view in the family, and every commit re-evaluates all of them. With 200 bindings, PROBE_AFTER=256 is crossed partway through the second commit after a stop. sharing then flips to true, and every view of that commit that has not started yet waits on a full lifted round. Scenario: 200 sessions on ?reach("s-N", Y), where Magic Sets restricts each own evaluation to about 1 ms but the unbound closure takes about 100 ms. The guard stops sharing after each probe, yet roughly every other commit pays a probe round that most views wait for. That breaks the required 'Millisecond query and update latency must not regress'. The guard only judges a round after it has run, so 'bounded by the same guard' does not bound how often a probe is paid for. Fix: count the probe interval in commits or rounds rather than summed own evaluations, for example per distinct revision or PROBE_AFTER * bindings. Optionally back off exponentially after repeated failed probes.
• ⚠️ src/protocol/subscription/reevaluate.rs:203 - The recorded decision asked that own_cost_us come from plan-cached executions only (feed record_own only on a cache hit). The round-1 fix subtracts the timed compile stages from total_us instead, which leaves compile work in the measurement. On a miss, execute_with_rules_tuples_cached (src/storage_engine/snapshot.rs:484) sets total_us = start.elapsed(). That still includes combine (parsing the query, closing over the rules, cloning them) and constant specialization, whose spec_us is never written to the breakdown (src/lib.rs:1484). With timing_mode = off there is no breakdown at all, and run_query falls back to started.elapsed(), which includes the whole compile. The first own evaluation is always a miss, and record_own stores it unaveraged and immediately enables sharing (parameterized.rs:505-515), so the first sharing decision is made against an inflated baseline. Later samples come only every 64 rounds with weight 1/8, so the inflation persists for hundreds of commits. Own plans can also keep missing once more than MAX_CACHED_PLANS=256 distinct session queries exist. Fix: carry plan_cached (compiled_now already exists) out through query_snapshot/QueryRows/Evaluated and call record_own only on a hit, as the decision specified.

🔧 Fix applied.
5 issues (4 warnings, 1 info) still open:

• ⚠️ src/protocol/subscription/parameterized.rs:132 - Lifting turns every view's bound constants into free variables without checking whether the engine relied on those constants to limit work (Magic Sets on recursive relations, constant specialization, SIP). The cost guard (line 449) only reacts after a shared round has already run. A new family starts with sharing: AtomicBool::new(true) (line 531), and after every PROBE_AFTER=256 own evaluations record_own (line 480) turns sharing back on. Each of those rounds evaluates the unbound query, and every view in the family waits on it (line 574). Concrete case: two sessions subscribe to ?reach("a", Y) and ?reach("b", Y) over a large edge graph. Each own query is a Magic-Sets-restricted millisecond evaluation. The first shared round and then every 256th probe compute the full transitive closure, which can take seconds and a lot of memory, or get truncated at max_result_rows only after the full computation, before either delta is delivered. This conflicts with the intent's "Millisecond query and update latency must not regress" for bound recursive standing queries, which previously stayed restricted. Suggested fix: don't lift constants on atoms whose closure reaches a recursive relation (the family can check this against the snapshot's rules when it is formed or when the rules change), and/or bound how long a probe round may run relative to own_cost_us.
• ⚠️ src/protocol/subscription/parameterized.rs:449 - The sharing guard accepts a round costing up to max(2, bindings/2) times a view's own evaluation. With 200 bindings that is up to 100x own cost on a single evaluation that every view waits for. Without sharing, those 200 own evaluations run in parallel on compute_permits threads (ncpu minus a reserve), so the last delta lands after about 200own/P. When P > 2 (any machine with 4 or more cores reserves 2), the guard therefore accepts rounds whose latency is up to P/2 times worse than unshared re-evaluation, and the first views' deltas wait for the whole round instead of about one own evaluation. The baseline is also inflated: own_cost_us is updated only on own evaluations, and in practice the only one before sharing starts is each view's first evaluation, which includes the plan-cache miss compile (about 7 ms per the intent's data), so worth is overstated. The intent says latency must not regress. Whether to trade per-delta latency for server CPU this way is a policy choice: consider bounding a round by the unshared parallel latency (for example ownbindings/compute_permits) rather than by CPU saving, and excluding compile time from own_cost_us.
• ℹ️ src/protocol/subscription/parameterized.rs:535 - Families are keyed by (kg, lifted query text), but kinds are checked only after lookup (line 518). When ?a("x", X) and ?a(1, X) both lift to ?a(_L0, X), the second creates a new family and families.insert overwrites the live first family's entry. Every later subscriber of the first kind then fails the kinds check and starts yet another family, overwriting again. Results stay correct, but alternating kinds keep fragmenting families into single-binding ones that never share. Fix: put shape.kinds in the map key.
• ⚠️ src/protocol/subscription/parameterized.rs:513 - The re-probe after a family stops sharing still fires far too often for large families, so the latency regression from round 1's lifted-round-unbounded finding is still reachable. Round 1's fix only changed the initial state (sharing now starts false) and left this cadence alone. own_since_stop counts own evaluations summed over every view in the family, and every commit re-evaluates all of them. With 200 bindings, PROBE_AFTER=256 is crossed partway through the second commit after a stop. sharing then flips to true, and every view of that commit that has not started yet waits on a full lifted round. Scenario: 200 sessions on ?reach("s-N", Y), where Magic Sets restricts each own evaluation to about 1 ms but the unbound closure takes about 100 ms. The guard stops sharing after each probe, yet roughly every other commit pays a probe round that most views wait for. That breaks the required 'Millisecond query and update latency must not regress'. The guard only judges a round after it has run, so 'bounded by the same guard' does not bound how often a probe is paid for. Fix: count the probe interval in commits or rounds rather than summed own evaluations, for example per distinct revision or PROBE_AFTER * bindings. Optionally back off exponentially after repeated failed probes.
• ⚠️ src/protocol/subscription/parameterized.rs:484 - Round 2's fix (commit 10da403) went further than the instructions, which only covered record_own. It also gates the sharing guard on ran.plan_cached. Any round whose lifted plan had to compile now skips the keeps_sharing check, so a slow round can never stop sharing. Concrete sequence: (1) A family starts sharing for the first time, or re-probes after a rule change. In both cases the lifted program is not in the plan cache. (2) That round runs the full unbound query, for example 100x a view's own cost, and is accepted without being judged. (3) The next commit runs another full round before the guard can react. So every first share and every rule change costs at least one extra slow round that every view waits for. (4) Worse, once more than MAX_CACHED_PLANS=256 programs exist for a rule set (other standing queries, samples, ad-hoc queries; arbitrary eviction at src/storage_engine/snapshot.rs:135), the lifted plan can be evicted between rounds. Every round then misses, none is ever judged, and sharing stays on no matter how slow the rounds are. Before this round, a miss round was still judged, using compile-subtracted timings. This conflicts with 'Millisecond query and update latency must not regress'. Fix: keep judging rounds that missed the cache. For example, on a miss use timing.total_us minus the compile stages for the round's cost, since the user's decision only restricts own-cost samples. At minimum, let a miss round still call stop_sharing when it is slow even after its compile time is excluded. Sibling site: the rounds/sample_due increment at line 494 is skipped on misses too, so samples also stop under eviction thrash.

🔧 Fix applied.
✅ Re-checked - no issues remain.

• ⚠️ There is no live latency comparison against the base commit yet. The paired session-scale benchmark (scripts/bench-sessions.sh --baseline-rev b260bf7 --sessions 1,10,50,100 --load-secs 10) has started its timed runs but had only finished the base commit at 1 session when this step had to report (write->delta p50/p99 25.4/37.0 ms under load). The 'millisecond query and update latency must not regress' requirement is unconfirmed until its summary (target/bench-sessions/latest/summary.md, log in the evidence directory) is reviewed or the step is re-run.
• ⚠️ live validation verdict: inconclusive (3 of 5 scenarios were driven live against the product); untested: Session-scale write->delta latency (1-100 sessions, voice pack) does not regress against the base commit, Adversarial: many sessions on bound recursive ?reach(root,Y), whose unbound closure is large, keep millisecond deltas (the cost guard stops sharing)
• Live validation: ⚠️ inconclusive - 3 of 5 scenarios driven live against the product

• cargo build --release --all-features --bin inputlayer-server and the perf-gate build at 33f55b2b
• node routing-check.mjs against the real inputlayer-server, default config (sharing on): 12 subscribers to ?view(<s>, X, "a") with s1..s10 plus integers 7 and 8, 7 mixed writes, each subscriber's pushed result compared with its own one-off query after every write
• Same routing check with INPUTLAYER_HTTP__RATE_LIMIT__SUBSCRIPTION_SHARE_PARAMETERIZED=false
• node recursive-latency.mjs smoke run (5 sessions on bound ?reach(root, Y) over 5 chains): deltas correct, p50 4.1 ms
• scripts/bench-sessions.sh --baseline-rev b260bf7a --sessions 1,10,50,100 --load-secs 10 (timed runs in progress; only the base commit at 1 session had finished)

🔧 Fix applied.
✅ Re-checked - no issues remain.

• Live validation: ✅ go - 4 of 5 scenarios driven live against the product

• run-adv.sh + adv-reach-sessions.mjs (evidence dir): 40 sessions each subscribed to ?reach("r-i", Y) over a shared 300-edge chain (unbound closure 57,190 rows / ~333 ms; bound 301 rows / ~11 ms). Each session writes a private edge every second for 30 s and times write→delta, with a missing/foreign-delta check and a final row-count consistency check. Runs alternated base b260bf7a, head d1715dc, base, head.
• scripts/bench-sessions.sh --baseline-rev b260bf7a --sessions 1,10,50,100,200 --load-secs 20 (perf-gate sessions, voice pack, 1 receipt/s per session)
• cargo test --release --lib -- subscription::parameterized (includes the new a_probe_too_slow_to_share_never_makes_a_view_wait)
• cargo test --release --test standing_query_tests

✅ No issues found.

✅ No issues found.

✅ No issues found.