Flags that serve a string, number or JSON value

Ouverte
#1,497 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@amarkanday y travaille déjà.

Depuis le 5/11/2026.

  • #1770 par @amarkanday — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
42/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go, javascript, python

Piste de recherche

Start with the feature-flag API and dashboard value models, then trace the evaluation response and the JavaScript, Python, and Go SDK paths, including local evaluators. Locate the tests and documentation that currently state flags are on or off only, especially around GET /feature-flags/user/{user_id} and the published 0.2.0 SDK behavior. Done means typed string, number, and JSON values can be configured and served without changing config, the legacy endpoint stays unchanged, supported SDKs and providers handle the new values and user attributes, and outdated local rulesets do not remain active indefinitely.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

A flag is on or off for each user today: evaluation answers enabled with config: null for every flag, a flag
request with variants is refused with 422, and default_value accepts only false. Serving one of several values
(a copy string, a limit, a JSON configuration) needs a multivariate experiment instead.

Expected:

  • A flag can carry a value of one type (string, number or JSON): the value a matching rule or the rollout serves, and
    the value the flag serves when it is off, set in the API and the dashboard. A rule or the rollout serves one of these
    two values; a weighted split among more values is out of scope here.
  • Evaluation returns the value in a new field. config keeps its current meaning, because existing SDKs read it in
    different ways; GET /feature-flags/user/{user_id} keeps answering {key: enabled}.
  • The JavaScript, Python and Go SDKs read typed values (and the JavaScript and Python local evaluators evaluate them),
    and the OpenFeature providers serve string, number and object values and send the user's attributes.
  • SDKs already published (0.2.0) keep working against a server with value flags, including in local evaluation: a
    ruleset they do not understand must not leave them answering from an old ruleset indefinitely.
  • The limitations page, the claims and the tests that state "on or off only" change with it.

Out of scope here: the other SDKs, which gain values as each is published.

Langage dominant
Python
Étoiles
0
Forks
4
Merge moyen
5 h 36 min
PR mergées (30 j)
509

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Controlvar/controlvar

Toutes les issues de Controlvar/controlvar

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.