Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -456,6 +456,10 @@ public enum FeatureFlag: String, CaseIterable {
"new_account_upgrade_prompt_flow"
case .endOfYear2025:
"end_of_year_2025"
case .encourageAccountCreation:
// Not the derived "encourage_account_creation" — that Firebase parameter still exists
// from the 2025 one-shot experiment, and its stale value would override the default.
"encourage_account_creation_recurring"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(non-blocking) The key rename fixes future reads, but it can't undo an override already persisted on device: AppDelegate.updateRemoteFeatureFlags (podcasts/AppDelegate.swift:306-317) writes ff-override-encourageAccountCreation into UserDefaults whenever the remote value's source is .remote, and that store is keyed by the flag's description (the raw value), not by the remote key. So any tester who ran a build containing #4985 while encourage_account_creation was serving false still has a stored false, and because the new encourage_account_creation_recurring parameter doesn't exist yet its configValue source is .default — the override block is skipped and nothing clears it. Those users keep the modal disabled.

Easiest mitigation: when creating encourage_account_creation_recurring in Firebase, publish it with an explicit true rather than leaving it absent — override(_:withValue:) deletes the stored key when the incoming value matches the flag default, so one remote fetch cleans the stale entry.

default:
rawValue.lowerSnakeCased()
}
Expand Down