chore(flags): use new /flags endpoint instead of /decide
#345
Conversation
|
@dmarticus Getting a Other than this and reverting the commit from ./scripts/prepare-release.sh that @marandaneto mentioned, LG to me. I don't see any other logic other than changing the endpoint affected |
|
@ioannisj I fixed the issue with PostHog/posthog#31798, can you give it a try on your side again? |
Yeah getting a response now. |
|
similar to PostHog/posthog-android#245 (comment) but here https://github.com/PostHog/posthog-ios/blob/479ce5ba9ce899dfe969dea7c88cd110adb800e7/PostHog/PostHogRemoteConfig.swift#L187C18-L187C35 and probably more places, @ioannisj would know more |
|
@ioannisj with this commit |
PostHog/PostHogApi.swift
Outdated
| ) else { | ||
| hedgeLog("Malformed decide URL error.") | ||
| let url: URL? | ||
| if config.remoteConfig { |
There was a problem hiding this comment.
I don't need to load the rest of the config if we're using RemoteConfig
There was a problem hiding this comment.
Hey @dmarticus, I think this won't fix the session replays that depend on flags issue. We do fetch sessionRecording from remote config to get linkedFlag value, but the way the code is currently structured the check expects both sessionRecording and feature flag values to be present when calling isRecordingActive
As it stands, session recording will only be evaluated from remote config payload (if config.remoteConfig is true), but it will always do so with cached flags (from a previous app run).
- enable session recording flag on dashboard
- first run, session recording evaluates to false (no cached flags)
- second run, session recording evaluates to true (from previously cached flags)
- turn off session recording flag on dashboard
- app run, session recording evaluates to true (from previously cached flags)
- additional run, session recording correctly evaluates to false
So here we can either:
- restructure the code so that we cache
linkedFlagfrom remote config call and re-evaluate when /flags is called with fresh flag values - always call with
/flags&config=trueso that we get the whole response for now
cc: @marandaneto can fact check me on this
PostHog/PostHogApi.swift
Outdated
| } else { | ||
| url = getEndpointURL( | ||
| "/flags", | ||
| queryItems: URLQueryItem(name: "v", value: "2"), URLQueryItem(name: "config", value: "true"), | ||
| relativeTo: config.host | ||
| ) | ||
| } |
There was a problem hiding this comment.
btw i fully used Claude on this, not sure if it's idiomatic.
💡 Motivation and Context
Update the iOS SDK to use the new
/flagsendpoint instead of the legacy/decideone. Part of the/flagsglobal rollout PostHog/posthog#33247This should be a safe change because
/flags&config=truereturns the exact same fields as/decidedoes, so we don't need to worry about missing any non-feature flag related fields. This is in response to this comment: #345 (comment)