regorus 0.9.1 — partial set rule with iterating body emits only one element

[jeromeajot]

regorus 0.9.1 — partial set rule with iterating body emits only one element

Version: regorus 0.9.1 (crates.io)
Tested on: macOS 26.4.1 (25E253) / Apple Silicon, rustc 1.95.0, library API + CLI binary

Summary

A partial set rule whose body iterates over a collection, e.g. s[x] if { some _, x in input.y }, adds only the first iteration's binding to the rule's set. Every subsequent binding is silently dropped. OPA produces all bindings.

The bug surfaces in both the library API (Engine::eval_rule) and the CLI (regorus eval). It does not surface for the equivalent set-comprehension form.

The same bug independently affects partial set rules with multiple bodies, each body emits at most one element, regardless of how many bindings would have satisfied that body.

Minimal reproducer

repro.rego:

package repro

import future.keywords.if
import future.keywords.in

violations[k] if {
    some k, _ in input.x
}

input.json:

{ "x": { "FOO": 1, "BAR": 2, "BAZ": 3 } }

Expected (per OPA 1.16.1)

opa eval -d repro.rego -i input.json 'data.repro.violations'

{ "BAR": true, "BAZ": true, "FOO": true }

Actual (regorus 0.9.1 CLI)

regorus eval -d repro.rego -i input.json 'data.repro.violations'

{ "BAR": true }

(Only one of the three bindings is added to the set.)

Same result via the library API

let mut engine = regorus::Engine::new();
engine.add_policy("repro.rego".to_string(), REGO.to_string())?;
engine.set_input_json(INPUT)?;
let v = engine.eval_rule("data.repro.violations".to_string())?;
// v contains a single-element set, not three.

Tested with regorus = "0.9" (default features + arc) and rustc 1.95.

Characterization — what works, what doesn't

All four variants run on the same input.json above. Output is the rule's value at data.repro.violations.

#	Variant	regorus 0.9.1	OPA 1.16.1	Notes
1	violations[k] if { some k, _ in input.x }	{BAR} (1)	{BAR, BAZ, FOO} (3)	iteration in single body —> bug
2	violations[entry] if { some k, _ in input.x; k in {"FOO","BAR","BAZ"}; entry := {"k": k} }	1 entry	3 entries	iteration + entry construction —> bug
3	Two bodies, each some k, _ in input.x; k in <subset>; entry := {...}	2 entries	3 entries	multi-body iteration —> bug, off-by-N
4	Three static bodies: violations[k] if { k := "FOO" } × 3	{BAR, BAZ, FOO} (3)	{BAR, BAZ, FOO} (3)	partial set rules with non-iterating bodies are fine
5	Comprehension: violations := {k | some k, _ in input.x}	{BAR, BAZ, FOO} (3)	{BAR, BAZ, FOO} (3)	comprehensions are fine

The bug is contained to partial set rules whose body produces multiple bindings via iteration. The element actually returned is the first one in iteration order (after sort, given object keys come back sorted).

The same shape with array input (input.x = ["FOO", "BAR", "BAZ"] and some _, v in input.x) reproduces the bug, regorus returns {FOO} only.

The single-body and multi-body variants both reproduce on regorus's own CLI binary built from the 0.9.1 crate, ruling out anything specific to library calling conventions.

Reproducer files

# repro.rego — variant #1, ultra-minimal
package repro

import future.keywords.if
import future.keywords.in

violations[k] if {
    some k, _ in input.x
}

// input.json
{ "x": { "FOO": 1, "BAR": 2, "BAZ": 3 } }

# install regorus CLI
cargo install --version 0.9.1 --example regorus regorus

# expected = three keys, observed = one key
regorus eval -d repro.rego -i input.json 'data.repro.violations'

# OPA reference
opa eval -d repro.rego -i input.json 'data.repro.violations'

Workaround

Rewrite affected partial set rules to set comprehensions:

# instead of:
violations[k] if { some k, _ in input.x; k in covered }

# write:
violations := {k | some k, _ in input.x; k in covered}

Comprehensions in regorus 0.9.1 produce the correct full set.

This workaround is not always tractable when the goal is to combine multiple distinct rule bodies into one set (e.g., one body for atomic identifiers and another for grouped identifiers, where each body has its own predicate logic). In that case the comprehension form requires expressing both bodies as branches of one comprehension's filter, readable for two branches, awkward for more.

Why this is not caught by the test suite of typical Rego policies

Many policy test suites assert count(violations) > 0 (boolean) or not allow (boolean) rather than exact entry counts. Both pass even when regorus returns one element instead of N. We discovered the bug while integrating the matrix-org/rust-opa-wasm runtime alongside regorus — opa-wasm and OPA agreed on entry counts, regorus disagreed. The count mismatch was the first signal.

Environment

$ rustc --version
rustc 1.95.0 (59807616e 2026-04-14)

$ regorus --version
regorus 0.9.1     # cargo install --version 0.9.1 --example regorus regorus

$ opa version
Version: 1.16.1

Cargo dependency line that reproduces:

regorus = { version = "0.9", default-features = false, features = ["full-opa", "arc"] }

Severity

For policies whose rule heads use s[x] if { some k, _ in input.y; ... } patterns, a common shape for "for each entity in input, emit a corresponding entry" rules, regorus silently emits one entry instead of N. Evaluations downstream (count(violations), iteration over violations, etc.) produce incorrect results without any error or warning.

[anakrish]

Hey @jeromeajot,

Thank you for reporting the issue, and such a thorough description.

There are two things going on here, one is a semantics clarification and the other is a genuine bug.

violations[k] vs violations[k] if vs violations contains k if

In OPA's Rego v1, the if keyword is changes the rule type for this specific case:

Syntax	v0 Rule Type	v0 Output	v1 Rule Type	v1 Output
violations[k] { ... }	Partial set	["BAR", "BAZ", "FOO"]	Compile error	—
violations[k] if { ... }	Partial object	{"BAR": true, "BAZ": true, "FOO": true}	Partial object	{"BAR": true, "BAZ": true, "FOO": true}
violations contains k if { ... }	Partial set	["BAR", "BAZ", "FOO"]	Partial set	["BAR", "BAZ", "FOO"]

This is documented in OPA's v0 → v1 upgrade guide. The v0 form violations [k] { ... } is intentionally a compile error in v1 because naively adding if changes the semantics. You must explicitly choose between:

• violations[k] if { ... } → partial object (key → true)
• violations contains k if { ... } → partial set

To illustrate, consider these two policies:

policy_v0.rego — run with --v0-compatible (OPA) or --v0 (regorus):

package test

import future.keywords.if

# Rego v0 does not require if keyword
# violations is a partial set.
violations[k] {
    input.x[k]
}

# With if, there is a subtle change in semantics.
# The rule is treated as a partial object.
violations_with_if[k] if {
    input.x[k]
}

With input {"x": {"FOO": 1, "BAR": 2, "BAZ": 3}}, OPA produces:

{
  "violations": ["BAR", "BAZ", "FOO"],
  "violations_with_if": {"BAR": true, "BAZ": true, "FOO": true}
}

policy_v1.rego — run in v1 mode (default):

package test

# Rego v1 requires if keyword.
# This is treated as a partial object.
violations_with_if[k] if {
    input.x[k]
}

OPA produces: {"violations_with_if": {"BAR": true, "BAZ": true, "FOO": true}}

So if your intent is a set, the correct v1 form is violations contains k if { ... }.

The bug: partial object rules without explicit assignment only emit one entry

That said, there is a real bug here. Even as a partial object rule, violations[k] if { ... } should produce entries for all matching bindings. OPA correctly produces {"BAR": true, "BAZ": true, "FOO": true}, but regorus currently only produces {"BAR": true}.

This is caused by an incorrect early-return optimization in the interpreter that short-circuits iteration after the first successful binding.

Thanks again for the report!

[anakrish]

Fix: Partial object rule produces only one entry (issue #712)

There are two independent bugs — one in the interpreter, one in the RVM compiler. Fix them separately.

---

Bug 1: Interpreter early-return (the reported issue)

File: src/interpreter.rs, function eval_output_expr_in_loop (line 1761)

Root cause: For violations[k] if { some k, _ in input.x }, the context has:

• rule_ref = violations (a simple Var — constant)
• key_expr = Some(k) (a variable — NOT constant)
• output_expr = None (implicit true)

At line 1775, is_constant_ref(&rule_ref) returns true for "violations".
Then at line 1799-1801, the else branch fires (no output_expr), sets output to Value::Bool(true), but never checks whether key_expr is constant. So is_const_rule stays true, causing early_return = true at line 1807-1808, which makes eval_some_in break after the first binding.

Fix: Add one line at line 1784-1785, right after the key_expr is used. Change:

if let Some(ke) = &key_expr {
    comps.push(self.eval_expr(ke)?);
}

To:

if let Some(ke) = &key_expr {
    is_const_rule = is_const_rule && Self::is_simple_literal(ke)?;
    comps.push(self.eval_expr(ke)?);
}

This uses is_simple_literal — a purely syntactic check (no scope lookup needed). It correctly preserves the optimization for constant keys like config["timeout"] if { ... } while disabling early-return for variable keys like violations[k] if.

Why this is correct:

• is_simple_literal checks if the expr node is a String/RawString/Bool/Null/Number literal
• A variable k is Expr::Var, not a literal → returns false → is_const_rule = false
• A constant "timeout" is Expr::String → returns true → optimization preserved

---

Bug 2: RVM compiler misclassifies partial objects as partial sets

File: src/languages/rego/compiler/rules.rs, function body at line 58-64

Root cause: Line 62 classifies Compr { refr: RefBrack, assign: None } as RuleType::PartialSet. But in OPA v1 semantics, violations[k] if { ... } (Compr + RefBrack + no assign) is a partial object (key→true), not a partial set.

The correct classification:

• RuleHead::Compr { refr: RefBrack, assign: Some(_) } → PartialObject (explicit value: p[k] := v if)
• RuleHead::Compr { refr: RefBrack, assign: None } → PartialObject (implicit value true: p[k] if)
• RuleHead::Set { .. } → PartialSet (p contains k if)

Fix: Change line 62 from RuleType::PartialSet to RuleType::PartialObject:

crate::ast::Expr::RefBrack { .. } => RuleType::PartialObject,

---

Testing

Add a YAML test file at tests/rvm/rego/cases/partial_object_rules.yaml with these cases:

1. Basic partial object with variable key — p[k] if { some k, _ in input.items } with multiple input items. Expected: object with all keys mapped to true.

2. Partial object with explicit value — p[k] := v if { some k, v in input.items }. Expected: object with all key-value pairs.

3. Partial object with constant key (optimization preserved) — p["fixed"] if { input.enabled }. Expected: {"fixed": true} when enabled.

4. Partial set with contains — p contains k if { some k, _ in input.items }. Expected: set (array) of all keys.

5. Multi-level key — p[a][b] if { some a, b in input.nested }. Expected: nested object.

6. Empty input — Same rules with empty input. Expected: empty object/undefined.

Also add interpreter test cases at tests/interpreter/cases/builtins/ or an appropriate location if a partial_rules test directory exists, or just rely on the RVM tests which run both paths.

The RVM test harness at tests/rvm/rego/mod.rs automatically runs both interpreter AND RVM and compares results, so these YAML tests verify both execution paths.

Important constraints

• Do NOT change the parser — it is correct
• Do NOT change make_rule_context or other interpreter functions
• Do NOT add new error types or change public API
• The interpreter fix is exactly ONE added line
• The RVM fix is changing one enum variant on one line
• Run cargo test --features rvm to verify
• Run cargo test --test opa --features opa-testutil for OPA conformance