Why doesn't the flagd provider reject JSON that doesn't satisfy the flagd schema?

[man85]

There is the JSON

{
  "$schema": "https://flagd.dev/schema/v0/flags.json",
  "flags": {
    "allowedProvisioningVersions": {
      "state": "ENABLED",
      "defaultVariant": "default",
      "variants": {
        "default1": [
          "1",
          "2"
        ]
      }
    }
  }
}

It fails validation with com.networknt:json-schema-validator:2.0.1 because default1 is an array. However, flagd doesn't reject this configuration. Why is that, and is this expected behavior?

We added some validation before applying the flags to the K8s ConfigMap, and it turned out that some previously used flag configurations failed validation.

[toddbaert]

The short answer is simply that a config being invalid doesn't mean it's useless. A single flag in 100 can have invalid targeting, for instance, while 99 others have a valid config; these will still work... so the safe thing is to warn and continue "best effort". It's also worth noting that by the time an invalid config gets to the provider, nothing can really be done to fix it, so this sort of validation is better done where the configuration is made (K8s, hosted system) etc... However:

It would be pretty easy to add a option to make this validation strict in the provider - it would basically just be passing a "true" here based on that option.

If you are really interested in this feature, maybe you are interested to help implement it? The place to start would be a parent issue in flagd, to decide on a name for this option, and track the implementation in all providers.

This also relates to: open-feature/flagd#1939

[man85]

Can we do it the other way around: modify the flagd schema so that arrays are allowed inside variants?

[toddbaert]

Can we do it the other way around: modify the flagd schema so that arrays are allowed inside variants?

That seems like a different question; but, yes possibly. We'd need to audit the OpenFeature SDKs themselves to see if all their "object resolvers" support top-level arrays. I suspect most do, but I'm not 100% sure. Then we could support this properly in flagd and the providers. It would be an enhancement.

FWIW, right now, you could certainly do this with a nested object, like:

{
  "$schema": "https://flagd.dev/schema/v0/flags.json",
  "flags": {
    "array-demo": {
      "state": "ENABLED",
      "defaultVariant": "default1",
      "variants": {
        "default1": {
          "myArray": [
            "1",
            "2"
          ]
        }
      },
      "targeting": {}
    }
  }
}

Here's a playground demo. Would that be sufficient? Is there a reason the array really needs to be at the top?