Feature-flag caches survive updateConfig API endpoint changes
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
- Área
- developer-experience
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
- Create a server or browser flags manager with a client ID and an initial API URL, and fetch an enabled flag from that endpoint.
- Call
manager.updateConfig({ clientId: "same-client", apiUrl: "https://second.example" })without changing the client or user. - Inspect
getSnapshot().flagsorgetMemoryFlags(): the old endpoint's flags remain. If the new endpoint returns 503, they still remain after an explicit refresh. - 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
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de databuddy-analytics/Databuddy
-
fix(dashboard): connecting one social identity shows loading on all provider buttonsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
databuddy-analytics/Databuddy#1106 ·
Los mantenedores suelen responder en 1 día
-
fix(dashboard): custom profile photo URL never renders, falls back to initialsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
databuddy-analytics/Databuddy#1104 ·
Los mantenedores suelen responder en 1 día
-
feat(dashboard): add Next.js and TanStack installation snippets to tracking setupPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
databuddy-analytics/Databuddy#1097 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
databuddy-analytics/Databuddy#1092 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
SDK cached reads still revalidate when evaluation is disabled or pendingPosiblemente ocupada @mvanhorn la tomó hace 2 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
databuddy-analytics/Databuddy#1091 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de databuddy-analytics/Databuddy
Issues similares
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
lingdojo/kana-dojo#32018 · 1 comentario · 5 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
paperclipai/paperclip#15751 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
BuilderIO/agent-native#7275 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día