chore(sync/openapi): align flag types with OpenFeature spec (add float)

[tomflenner-dg]

While working with the sync OpenAPI specification in openfeature/cli, I noticed an inconsistency regarding numeric flag types, specifically missing support for floating-point values.

Current OpenAPI definition

cli/api/v0/sync.yaml

Lines 22 to 47 in 144eb0f

	FlagDefaultValue:
	description: Default value for a flag (can be boolean, string, integer, or object)
	oneOf:
	- type: boolean
	- type: string
	- type: integer
	- type: object
	ManifestFlag:
	type: object
	required:
	- key
	- type
	- defaultValue
	properties:
	key:
	type: string
	description: Unique flag key within the flag set.
	example: search-rollout
	name:
	type: string
	description: Human-friendly flag name. Defaults to the key when omitted.
	example: Search rollout
	type:
	type: string
	description: Flag data type.
	enum: [boolean, string, integer, object]

Both:

• FlagDefaultValue.oneOf
  

  cli/api/v0/sync.yaml

  Lines 24 to 28 in 144eb0f

  	oneOf:
  	- type: boolean
  	- type: string
  	- type: integer
  	- type: object

• ManifestFlag.type.enum
  

  cli/api/v0/sync.yaml

  Line 47 in 144eb0f

  enum: [boolean, string, integer, object]

are missing a floating-point / number representation.

Why this is incorrect per OpenFeature spec

https://openfeature.dev/specification/sections/flag-evaluation/#conditional-requirement-1331
https://openfeature.dev/specification/types/#number

This clearly establishes that floating-point values are a first-class concept in OpenFeature.

Existing manifest schema already supports floats : the current v0 flag manifest JSON Schema already allows float flags: flag-manifest.json#L37

This creates a mismatch where:

• JSON Schema ✅ allows float flags
• Sync OpenAPI spec ❌ does not

Impact

Because floating-point is missing from the OpenAPI spec:

• Code generation for provider servers becomes incorrect or incomplete

Suggested fix

Add number (or float) to:

• FlagDefaultValue.oneOf
• ManifestFlag.type.enum

I’m happy to provide a PR once the expected direction is agreed upon. 👍

[tomflenner-dg]

Probably missing here also :

cli/api/v0/sync.yaml

Line 231 in 144eb0f

enum: [boolean, string, integer, object]

cli/api/v0/sync.yaml

Line 356 in 144eb0f

enum: [boolean, string, integer, object]

[beeme1mr]

Yes, I think that was just a miss when we initially implemented this. It looks like we could just replace integer with the more generic number.

[tomflenner]

I am wondering if using only number will be enough. For example, when generating a Fiber server using the spec that only contains number using

go run github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest \
    -generate types,fiber-server,strict-server,spec \
    -package testserver \
    -o api/testserver/server.gen.go \
    api/sync.yaml

will provide these types :

// FlagDefaultValue0 defines model for .
type FlagDefaultValue0 = bool

// FlagDefaultValue1 defines model for .
type FlagDefaultValue1 = string

// FlagDefaultValue2 defines model for .
type FlagDefaultValue2 = float32

// FlagDefaultValue3 defines model for .
type FlagDefaultValue3 = map[string]interface{}

So we loose strong type in golang here by only have access to float32. Since the manifest support both integer and float

cli/schema/v0/flag-manifest.json

Lines 33 to 38 in 144eb0f

	{
	"$ref": "#/$defs/integerFlag"
	},
	{
	"$ref": "#/$defs/floatFlag"
	},

Will this not cause issue on the generated manifest ? e.g ending with only flagType=float