Feature-flag caches survive updateConfig API endpoint changes

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.

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.