[flagd] [FEATURE] Harden Hashing Consistency And Add Support For Non-string Attributes in Fractional Evaluation

[cupofcat]

Implement this ADR for the flagd provider.

[josecolella]

Analysis of ADR: Fractional Non-String Rand Units

ADR Requirements Summary

The ADR specifies two core changes to fractional evaluation logic:

1. Non-string attribute support: Users must be able to use both string and non-string variables (integers, booleans, floats, objects, datetime, null) as the primary input for fractional evaluation. Arrays are explicitly excluded.
2. Cross-platform hashing consistency: The same value must result in the same bucket assignment regardless of the provider language/platform. This is achieved by encoding all values to bytes using RFC 8949 (CBOR) with deterministic serialization before hashing.

The encoding follows a precedence-based approach:

• If the first element of the fractional rule evaluates to a non-array type, encode it deterministically to bytes via CBOR and hash it
• If absent, fall back to targetingKey (which must be a string)
• Non-string targetingKey values trigger an error

Applicability to the Ruby flagd Provider

After reviewing the provider codebase, the Ruby flagd provider is a pure RPC (gRPC) client. It does not perform any client-side flag evaluation:

• Client (lib/openfeature/flagd/provider/client.rb) sends all resolve requests to a remote flagd server via gRPC stubs (ResolveBoolean, ResolveString, ResolveFloat, ResolveInt, ResolveObject)
• There is no in-process evaluation engine, no fractional evaluation logic, no hashing code, and no JSON Logic / targeting rule processing in the Ruby provider
• The fractional evaluation (including the hashing described in the ADR) is handled entirely server-side by the flagd instance

The provider only passes the evaluation context to flagd via Google::Protobuf::Struct — the server is responsible for interpreting targeting rules and performing fractional bucketing.

Recommendation

No changes are needed in the current Ruby flagd provider for this ADR. The fractional evaluation logic, including hashing and bucketing, runs server-side on the flagd instance. Upgrading the flagd server to a version that implements this ADR is sufficient.

If the Ruby provider adds in-process evaluation mode in the future (as some other language providers have), this ADR would need to be implemented at that time as part of the in-process evaluation engine. I'd recommend:

1. Closing this issue as not applicable to the current RPC-mode provider, or
2. Converting it to a tracking issue that is deferred until in-process evaluation support is added to the Ruby provider

🤖 Jose's AI agent