Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[sdk/local-evaluation] getEnvironmentFlags() evaluations are not tracked for analytics

Abierto Apto para principiantes
  • ¿Algo no está bien?
#304 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
85/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
nodejs, typescript
Área
analytics

Línea de trabajo

La incidencia apunta a getEnvironmentFlagsFromDocument en sdk/index.ts alrededor de la línea 640, donde se llama a Flags.fromEvaluationResult sin el procesador de analítica. Compáralo con getIdentityFlagsFromDocument cerca de la línea 669, que ya pasa this.analyticsProcessor. Ejecuta el script de reproducción de la incidencia: está terminado cuando la ejecución local muestra {"my_feature":5}, igual que la remota.

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

Descripción

Problem

With enableLocalEvaluation: true, flag evaluations from getEnvironmentFlags() are never counted towards analytics. The same code against the same environment reports usage correctly when local evaluation is off, so flag analytics are effectively unavailable to anyone evaluating locally.

The cause looks like a missed argument in getEnvironmentFlagsFromDocument:

// sdk/index.ts:640
const flags = Flags.fromEvaluationResult(evaluationResult);

The other three evaluation paths all pass the processor through:

  • getIdentityFlagsFromDocument (local) -> sdk/index.ts:669, passes this.analyticsProcessor
  • getEnvironmentFlagsFromApi (remote) -> sdk/index.ts:689
  • getIdentityFlagsFromApi (remote) -> sdk/index.ts:710

Since the other local path already tracks, this doesn't look like a deliberate decision to skip analytics during local evaluation.

For what it's worth, the Python client passes it in the equivalent method, so the two SDKs behave differently here:

# flagsmith/flagsmith.py:535, _get_environment_flags_from_document
return Flags.from_evaluation_result(
    evaluation_result=evaluation_result,
    analytics_processor=self._analytics_processor,
    default_flag_handler=self.default_flag_handler,
)

Impact

getEnvironmentFlags() is the common path for server-side usage, and local evaluation is the recommended mode there, so this combination silently reports no usage at all. Nothing warns or errors, and the dashboard just shows the flag as unused. We ran into it while using analytics to decide which stale flags were safe to delete, where a flag wrongly showing zero evaluations is the dangerous direction to be wrong in.

Reproduction

Standalone script, no account needed; it stubs the API locally and compares the two modes.

const http = require('node:http');
const { Flagsmith } = require('flagsmith-nodejs');

const ENV_DOC = {
  api_key: 'ser.repro',
  project: { id: 1, name: 'repro', organisation: { id: 1, name: 'org', feature_analytics: true,
    stop_serving_flags: false, persist_trait_data: true }, hide_disabled_flags: false, segments: [] },
  feature_states: [{ feature: { id: 1, name: 'my_feature', type: 'STANDARD' },
    enabled: true, feature_state_value: null, featurestate_uuid: 'fs-1', multivariate_feature_state_values: [] }],
  identity_overrides: []
};
const API_FLAGS = [{ feature: { id: 1, name: 'my_feature', type: 'STANDARD' },
  enabled: true, feature_state_value: null }];

(async () => {
  const server = http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    if (req.url.includes('environment-document')) return res.end(JSON.stringify(ENV_DOC));
    if (req.url.includes('/flags')) return res.end(JSON.stringify(API_FLAGS));
    res.end('{}');
  });
  await new Promise(r => server.listen(0, '127.0.0.1', r));
  const apiUrl = `http://127.0.0.1:${server.address().port}/api/v1/`;

  async function run(local) {
    const f = new Flagsmith({ environmentKey: 'ser.repro', apiUrl,
      enableLocalEvaluation: local, enableAnalytics: true });
    const flags = await f.getEnvironmentFlags();
    for (let i = 0; i < 5; i++) await flags.isFeatureEnabled('my_feature');
    const buf = { ...(f.analyticsProcessor?.analyticsData ?? {}) };
    f.environmentDataPollingManager?.stop();
    console.log(`${local ? 'LOCAL ' : 'REMOTE'} -> buffer ${JSON.stringify(buf)}`);
  }

  await run(true);
  await run(false);
  server.close();
})();

Observed:

LOCAL  -> buffer {}
REMOTE -> buffer {"my_feature":5}

Expected: both report {"my_feature":5}.

Version: [email protected] (current npm latest), Node 24.13.0. Line numbers above are from main as of today, which still has the same call.

Workaround

Calling trackFeature(name) on the processor after each evaluation restores the counts, which is what we're doing for now.

Lenguaje dominante
TypeScript
Estrellas
30
Forks
29
Merge medio
7 d 23 h
PR fusionados (30 d)
3

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 Flagsmith/flagsmith-nodejs-client

Todos los issues de Flagsmith/flagsmith-nodejs-client

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.