Repository navigation
bug: literal keyword bound in rule call resolves as entity UUID, silently mismatches keyword values in rule body #298
Description
Description
In v1.2.0, when a literal keyword is used to bind a rule argument at the call site, it is resolved to its entity UUID. If that bound variable is then used in a value position within the rule body, it silently fails to match stored Value::Keyword facts — returning empty results instead of the expected matches.
Reproduction
(transact [[:bob :employee/manager :alice]])
(transact [[:carol :employee/manager :alice]])
(rule [(reports-to ?emp ?mgr) [?emp :employee/manager ?mgr]])
; Direct query — works correctly:
(query [:find ?emp :where [?emp :employee/manager :alice]])
; → returns bob and carol
; Rule with literal in body — works:
(rule [(manages ?emp) [?emp :employee/manager :alice]])
(query [:find ?emp :where (manages ?emp)])
; → returns bob and carol
; Rule with variable bound at call site — silently returns empty:
(query [:find ?emp :where (reports-to ?emp :alice)])
; → {"results":[],"variables":["?emp"]} ← BUG: should return bob and carol
Root cause hypothesis
When :alice is used in the rule call (reports-to ?emp :alice), it appears to be resolved as an entity UUID (as if it were in entity position). The rule body [?emp :employee/manager ?mgr] then tries to match against stored facts where :employee/manager values are Value::Keyword(":alice"). The UUID doesn't match the keyword — hence empty results.
Direct queries handle this correctly; the bug is specific to bound variable propagation from rule call sites into rule body value-position patterns.
Contrast with entity-position binding (works)
(transact [[:a :edge :b][:b :edge :c]])
(rule [(reach ?x ?y) [?x :edge ?y]])
; Binding ?x (entity position) via literal — works:
(query [:find ?y :where (reach :a ?y)])
; → returns :b and :c
Entity-position binding works because entity values are stored as UUIDs consistently.
Affected versions
Introduced in v1.2.0. v1.1.1 is not affected.
Workaround
Look up the target entity via a fact pattern to get the UUID, then pass it into the rule:
[?alice :employee/title "CEO"]
(reports-to ?emp ?alice)
Relation to #297
Both bugs are triggered by literal keyword binding in rule calls, but manifest differently:
- This issue: silent empty results (non-recursive rules, value-position binding)
- bug: magic sets rewriting rejects intermediate variables when first rule arg is bound by literal keyword #297: "Unbound variable in rule head" error (recursive rules with intermediate variables)
Activity
Merge pull request #300 from project-minigraf/worktree-fix+magic-sets…
chore: bump version to 1.2.1