Affected versions: introduced in PR #225, released in 7.0.0 (2026-03-27). Affects any app upgrading from ≤6.x to ≥7.0.0.
Description
7.0.0 scoped the feature cache file by clientKey to fix the multi-instance collision in #224:
The scoping itself is the right fix, but there is no migration: on the first launch after an app ships the upgraded SDK, the existing cache is invisible under the new name. Every user cold-starts as if freshly installed — flags evaluate to code defaults until the first network fetch completes, and users who launch offline (or whose fetch fails) stay on defaults for the whole session. The orphaned FeatureCache.txt is also never cleaned up.
At fleet scale this is incident-shaped: a routine SDK version bump causes a synchronized, app-wide "flags unavailable" window across the entire user base on update day, which is easy to misread as cache corruption or an outage.
Suggested fix
One-time best-effort migration in the new read path: if FeatureCache_<clientKey>.txt does not exist and the legacy FeatureCache.txt does, rename (or copy) it to the scoped name before reading, then delete the legacy file.
Caveat: in the multi-instance scenario from #224 the legacy file's contents may belong to a different clientKey — but that's precisely the already-broken case 7.0.0 fixed, and the payload self-corrects on the first successful fetch. For the single-instance majority, migration preserves exactly the right data. A line in the README changelog calling out the upgrade behavior would also help integrators plan (e.g. expect one cold start without cache if migration isn't feasible).
Affected versions: introduced in PR #225, released in 7.0.0 (2026-03-27). Affects any app upgrading from ≤6.x to ≥7.0.0.
Description
7.0.0 scoped the feature cache file by clientKey to fix the multi-instance collision in #224:
FeatureCache.txt(FeaturesViewModel.kt at 6.1.5, L122/L244)FeatureCache_<clientKey>.txt(GrowthBookSDK.kt at 7.1.1, L85)The scoping itself is the right fix, but there is no migration: on the first launch after an app ships the upgraded SDK, the existing cache is invisible under the new name. Every user cold-starts as if freshly installed — flags evaluate to code defaults until the first network fetch completes, and users who launch offline (or whose fetch fails) stay on defaults for the whole session. The orphaned
FeatureCache.txtis also never cleaned up.At fleet scale this is incident-shaped: a routine SDK version bump causes a synchronized, app-wide "flags unavailable" window across the entire user base on update day, which is easy to misread as cache corruption or an outage.
Suggested fix
One-time best-effort migration in the new read path: if
FeatureCache_<clientKey>.txtdoes not exist and the legacyFeatureCache.txtdoes, rename (or copy) it to the scoped name before reading, then delete the legacy file.Caveat: in the multi-instance scenario from #224 the legacy file's contents may belong to a different clientKey — but that's precisely the already-broken case 7.0.0 fixed, and the payload self-corrects on the first successful fetch. For the single-instance majority, migration preserves exactly the right data. A line in the README changelog calling out the upgrade behavior would also help integrators plan (e.g. expect one cold start without cache if migration isn't feasible).