You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fact params is not working when I am using fact in evaluationDetails > currentValue #424
I am using these params to create a rule. When rule is failing I want it to return currentValue by resolving fact documentsCount . Although It is resolving this fact documentsCount but not with the params which I passed. The params receiving params in fact fact resolver is {}.
{
baseNumber: 1,
evaluationDetails: {
code: "RuleEventErrorCode",
currentValue: {
fact: "documentsCount",
params: {
status: "approved",
hasPayments: true,
},
},
message: 'The documents number does not meet the requirements',
targetValue: {
fact: "stdDocCount",
},
}
};
Hi @dlsemwal, I looked into this and was able to reproduce the issue. It behaves a little differently from what was originally described though.
What's actually happening: Fact references inside nested event.params are never resolved, regardless of whether they have params or not. The params: {} you saw in your resolver was most likely coming from another place (for example, the rule conditions), not from currentValue.
Root cause:RuleResult.resolveEventParams (src/rule-result.js#L18) only loops over the top-level properties in event.params. almanac.getValue already handles params correctly, but it's only called for top-level values. So if a { fact: ... } reference is nested deeper, it never gets resolved.
Proposed fix: Update resolveEventParams to walk through event.params recursively. It would traverse plain objects and arrays, and whenever it finds a { fact: ... } object, it resolves it and stops traversing that branch (so the fact's own params stay untouched). This doesn't require a new API, stays behind the existing replaceFactsInEventParams flag, and doesn't change the current top-level behaviour.
The only possible behaviour change is for anyone who was intentionally relying on nested { fact: ... } objects being left untouched when this flag is enabled. If that's a concern, we could introduce a separate opt-in (something like replaceFactsInEventParams: 'deep'). Personally, I think recursive resolution matches what this flag was always expected to do.
@chris-pardy does that sound reasonable? If so, I'm happy to open a PR with the fix and add a test case based on the example from this issue.
Activity
AayushOjha commentedon Jul 13, 2026
Hi @dlsemwal, I looked into this and was able to reproduce the issue. It behaves a little differently from what was originally described though.
What's actually happening: Fact references inside nested
event.paramsare never resolved, regardless of whether they haveparamsor not. Theparams: {}you saw in your resolver was most likely coming from another place (for example, the rule conditions), not fromcurrentValue.Minimal repro (v7.3.2,
replaceFactsInEventParams: true):Output:
Root cause:
RuleResult.resolveEventParams(src/rule-result.js#L18) only loops over the top-level properties inevent.params.almanac.getValuealready handlesparamscorrectly, but it's only called for top-level values. So if a{ fact: ... }reference is nested deeper, it never gets resolved.Proposed fix: Update
resolveEventParamsto walk throughevent.paramsrecursively. It would traverse plain objects and arrays, and whenever it finds a{ fact: ... }object, it resolves it and stops traversing that branch (so the fact's ownparamsstay untouched). This doesn't require a new API, stays behind the existingreplaceFactsInEventParamsflag, and doesn't change the current top-level behaviour.The only possible behaviour change is for anyone who was intentionally relying on nested
{ fact: ... }objects being left untouched when this flag is enabled. If that's a concern, we could introduce a separate opt-in (something likereplaceFactsInEventParams: 'deep'). Personally, I think recursive resolution matches what this flag was always expected to do.@chris-pardy does that sound reasonable? If so, I'm happy to open a PR with the fix and add a test case based on the example from this issue.