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

Feature-flag caches survive updateConfig API endpoint changes

Abierto
#1,090 0 comentarios 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript

Línea de trabajo

Start at BaseFlagsManager.updateConfig() and the existing context-change check (clientId, environment, user), plus the cache-clear and request-generation guards it invokes. Locate the four unit regression tests for endpoint changes, failed replacements, late responses and default-URL equivalence, and the Chromium feature-flag browser persistence tests. Note that an external prepared commit (a5118325) already covers this and awaits maintainer acceptance — confirm with the maintainer before starting, since done means those regressions pass with apiUrl included in the effective-context comparison.

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

Descripción

Describe the bug

BaseFlagsManager.updateConfig() treats a change to clientId, environment, or user as a new evaluation context, but does not treat a change to apiUrl the same way. With the same client and user, switching servers keeps the previous server's flag values in memory and browser storage. A late response from the old server can also overwrite values fetched from the new one.

To Reproduce

  1. Create a server or browser flags manager with a client ID and an initial API URL, and fetch an enabled flag from that endpoint.
  2. Call manager.updateConfig({ clientId: "same-client", apiUrl: "https://second.example" }) without changing the client or user.
  3. Inspect getSnapshot().flags or getMemoryFlags(): the old endpoint's flags remain. If the new endpoint returns 503, they still remain after an explicit refresh.
  4. Alternatively, delay a bulk response from the first endpoint, switch to the second endpoint and fetch its flags, then release the first response. The old response replaces the second endpoint's flags.

The URLs above represent intercepted test endpoints, not public services used for this report.

Expected behavior

Changing the effective API URL should clear the previous evaluation state and browser persistence, and invalidate requests from the previous endpoint. Reads should use the new endpoint. Making the default URL explicit should preserve the existing cache.

Screenshots

Not applicable. Regression assertions inspect the returned flag values and browser storage.

Environment (please complete the following information):

  • OS: macOS arm64
  • Browser: Chromium 148.0.7778.96 for the browser regression
  • Runtime: Bun 1.4.1, pinned by the repository
  • SDK source: current staging, based on 89f418889b394d66754fdf31f2b0472a2372f10d

Additional context

A local patch adds the effective API URL comparison to the existing context-change check. It reuses the cache clear and request-generation guards. Four unit regressions cover endpoint changes, failed replacements, late responses and equivalent default URLs; a Chromium regression covers browser persistence.

Prepared change: commit a5118325b441b7e25302393db3ca8fa09be02737 on Iflaqbhat:codex/flags-api-url-cache. No PR has been submitted; maintainer acceptance and contributor code review are pending.

Three regressions failed against the original implementation. With the patch, SDK unit tests (93), Chromium feature-flag tests (31), repository lint, 37 typecheck tasks and the standard root test run pass. Optional database integration suites were not enabled.

The contributor also manually ran the built Node SDK against synthetic loopback HTTP endpoints: the initial value was first, switching endpoints immediately cleared the snapshot before returning second, and switching to an endpoint returning 503 left the flags empty. All checks completed successfully.

Would you accept a focused external contribution for this behavior against staging? No matching issue or overlapping open PR was found during the check on 2026-10-06.

AI usage disclosure

OpenAI Codex identified the bug, implemented the local patch, added tests and ran automated verification. The contributor completed the local Node SDK manual check described above. Contributor code review remains pending before any PR submission.

Lenguaje dominante
TypeScript
Estrellas
1.2k
Forks
220
Merge medio
12 h 12 min
PR fusionados (30 d)
295

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 databuddy-analytics/Databuddy

Todos los issues de databuddy-analytics/Databuddy

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.