flagd: Implement $evaluators/$ref resolution in in-process provider

[jonathannorris]

Summary

The flagd in-process provider does not implement $evaluators/$ref resolution. Flag configurations that use shared targeting rule fragments via $evaluators will silently fail — the raw {"$ref": "evaluatorName"} objects are left in the targeting rules and passed to the JSONLogic engine, where they cause evaluation errors.

All other SDKs with in-process evaluation (Go, Java, JS/TS, .NET, Python) implement this feature.

Expected Behavior

Given a flag configuration like:

{
  "$evaluators": {
    "emailSuffix": { "ends_with": [{ "var": "email" }, "@example.com"] }
  },
  "flags": {
    "my-flag": {
      "targeting": { "if": [{ "$ref": "emailSuffix" }, "variant-a", "variant-b"] }
    }
  }
}

The $ref should be replaced with the corresponding evaluator body at parse time, producing:

{ "if": [{ "ends_with": [{ "var": "email" }, "@example.com"] }, "variant-a", "variant-b"] }

Current Behavior

flag_parser.rs deserializes the flag configuration via serde_json::from_value with no evaluator transposition. The $evaluators block is ignored and $ref objects remain in targeting rules.

Implementation Notes

The approach used by all other SDKs is regex-based string replacement on the serialized JSON at parse time:

1. Extract the $evaluators map from the configuration
2. For each evaluator, build a regex matching "$ref": "<name>" (with the enclosing {})
3. Replace matches with the serialized evaluator body (stripping outer braces)
4. Deserialize the result

This should be added to crates/flagd/src/resolver/in_process/model/flag_parser.rs.

Related

• [BUG] $evaluators/$ref resolution: no parse-time validation, non-deterministic ordering, and missing Rust support flagd#1875 — Cross-SDK $evaluators/$ref resolution inconsistencies

[aepfli]

before we start working on this, we should shortly evaluate, if it is feasible to extract the evaluator in an own module/crate like we are currently doing for some languages.

[erenatas]

before we start working on this, we should shortly evaluate, if it is feasible to extract the evaluator in an own module/crate like we are currently doing for some languages.

I will work on this

[aepfli]

i have a repo ready - with the rust sdk as a source and ref working