Flags that serve a string, number or JSON value

Abierto
#1,497 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, javascript, python

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
0
Forks
4
Merge medio
5 h 19 min
PR fusionados (30 d)
503

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Controlvar/controlvar

Todos los issues de Controlvar/controlvar

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.