feat(feature-flags): support quota limiting for feature flags #228
Conversation
There was a problem hiding this comment.
lets figure out PostHog/posthog-js-lite#403 (comment) first before merging this
posthog/src/main/java/com/posthog/internal/PostHogDecideResponse.kt
Outdated
Show resolved
Hide resolved
| config.cachePreferences?.let { preferences -> | ||
| preferences.remove(FEATURE_FLAGS) | ||
| preferences.remove(FEATURE_FLAGS_PAYLOAD) | ||
| } |
There was a problem hiding this comment.
what should happen if session replay uses a feature flag and now is quota limited, should it stop working as well? if so, I guess we can also do preferences.remove(SESSION_REPLAY) if session replay has a linkedFlag value.
There was a problem hiding this comment.
Oh, yeah, I didn't think of that scenario – can you tell me more about how session replay with flags works? I'm fine removing it but I don't really understand how session replay and flags overlap in this context.
There was a problem hiding this comment.
@Posthog/team-replay would know more but the implementation is straightforward.
https://github.com/PostHog/posthog-android/blob/41ac8e9dbf989348823052c8c0f14c9c0d1fa2fd/posthog/src/main/java/com/posthog/internal/PostHogFeatureFlags.kt#L39C17-L68
https://github.com/PostHog/posthog/blob/31427d51f6a4aa91b45b3f4c49ef019f22c503d3/posthog/api/decide.py#L489
if /decide returns a linkedFlag value, that means we have to evaluate this flag locally, so the current approach will break session replay even if you have recordings quota.
now the question is, if you have recordings quota, you don't have flags quota, but session replay configs is enabled behind a flag, should it work or not?
There was a problem hiding this comment.
well, it should fail closed
generally speaking folk are setting a linked flag to reduce cost/volume. so failing open would be nasty
so, I have a linked flag, but I am past flag quota, decide/config continues to return the linked flag for replay, the SDK never shows it as received because i'm past quota, and replay never starts
There was a problem hiding this comment.
then i think the UX is all around how we notify people about being past quota. feels way more important for flags than other products
There was a problem hiding this comment.
the current approach will silently disable session replay since the linked flag won't exist, which will be one more edge case to debug missing recordings on SDKs.
is that the expectation?
ps: there's the quota limiting logging but it's not really specific about session replay, so folks won't get it right away, I think.
There was a problem hiding this comment.
yep, at least failing closed :)
ideally we'd register a super property on events if replay or flags or etc are past their quota for debugging (obvs doesn't help if events are past quota)
but yep, the onward journey will be the thing
|
@dmarticus this should be done for iOS as well right? is your team doing it? or do you need help from @ioannisj |
Yup, I did it here: PostHog/posthog-ios#308, tagged you and Ioannis for review :) |
|
@marandaneto addressed your feedback but my tests are failing and I can't make head or tails of the kotlin build error; any chance you could give me a hand getting it over the line? |
sure, here we go |
|
@dmarticus should I merge and release this? |
| @@ -1,5 +1,9 @@ | |||
| ## Next | |||
|
|
|||
| ## 3.11.3 - 2025-02-24 | |||
There was a problem hiding this comment.
| ## 3.11.3 - 2025-02-24 | |
| ## 3.11.3 - 2025-02-25 |
with PostHog/posthog#28564, we now start to respond different with the /decide and /local_evaluation APIs if users have gone over their quota limit. Now we need to change the SDKs to handle these new responses.