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

[cupofcat]

• Review the current Gherkin suite to ensure any potential inconsistencies are captured
• Support non-string randomisation units (e.g. bytes) in fractional without casting
• Ensure consistency of hashing and bucketing across all providers (languages), no matter the internal encoding choices made by compilers and platforms

Out of scope for this issue:

• Bucketing improvements
• Any new advanced features

[cupofcat]

Can I assign this to myself?

Today, when evaluating the fractional targeting rule, if the first argument inside fractional evaluates to a string, it's used as the hashing input, and, subsequently as bucketing value. Otherwise, the evaluation context is searched for the "targetingKey" property, treated as string, string-concatenated with flagKey and that is used as hashing input instead.

In both cases, the input is assumed to be a string. As mentioned by @tangenti, this is problematic :

Consistency of casting and encoding across all supported languages can be a painful problem.. Hashing the bytes directly don't have this problem.

I think we can solve it like this:

• no changes to the schema
• if someone wants to use bytes, they just use "var" directly, or, they can also use "targetingKey"
• providers, when evaluating, they check the type of var / targetingKey; this should work as, I think, all our providers today are strongly typed
• if the type is byte we call murmur's Sum32 method directly rather than StringSum32

I would love to hear opinions about the user experience. One challenge I see is this: Today, the suggested best practice, when not using targetingKey, is to use "cat" and join "flagKey" with "var". However, cat outputs a string (at least in some languages). If using "var" without "cat", the user would have to make sure that "flagKey" is included in "var" already. An alternative could be using merge, which outputs a list, and treat that specially in the implementation.

[beeme1mr]

I would love to hear opinions about the user experience. One challenge I see is this: Today, the suggested best practice, when not using targetingKey, is to use "cat" and join "flagKey" with "var". However, cat outputs a string (at least in some languages). If using "var" without "cat", the user would have to make sure that "flagKey" is included in "var" already. An alternative could be using merge, which outputs a list, and treat that specially in the implementation.

I've been thinking about this too. Using a custom context with "cat" requires you to be very defensive with your rule, or you run the risk of always bucketing by the same value. Thankfully, it's possible to be defensive and check for the existence of evaluation context prior to executing fractional. However, that makes the rule more verbose and difficult to understand. Perhaps accepting a list as you suggest would be the most straightforward, as long as we had a way to skip fractional if any of the values are undefined.

[cupofcat]

Was thinking about this more. The problem I am thinking of solving is the ability to salt "var"s directly in fractional logic, similarly to how it's possible today with "cat". Perhaps this is not a problem that needs solving yet, until someone asks for it :)

If we do want to solve, we can also add another custom JSONLogic operator, e.g. "salt" or "bytesalt" or similar. This could be a followup PR, if needed.

So, for the M1 (MVP), my proposal is:

• evaluate the first argument in fractional, just like today
• if it's not a string, use regular bytes hashing
• otherwise use existing behavior

The users would need to make sure that the evaluation, based on provided evaluation context, has a non-string type. One intended use would be to just do:

"fractional": [
  {
     "var": "my-non-string-var" }
  },
  // Split definitions contain an array with a variant and relative weights
  [
    // Must match a variant defined in the flag definition
    "red",
    // The probability this variant is selected
    50
  ],
  [
    // Must match a variant defined in the flag definition
    "green",
    // The probability this variant is selected
    50
  ]
]

In the future we can add additional features:

• ability to add salts for non-string variables directly in fractional logic (e.g. through new custom operator, or through using merge)
• ensure that all the providers use consistent encoding for strings (e.g. UTF8)