Resiliency and JSON Flags Spec

[EDsCODE]

Problem

• enable users to pass payloads (JSON) with feature flags when they're evaluated

Implementation

Frontend

• Feature flag creation-edit interface should allow for inclusion of payloads both on simple boolean flags and multivariate flags
  • simple flags can have payloads for true/false evaluation results
    • @neilkakkar : Q -> Payload makes sense only for true evaluation right, as false means it's disabled/inactive?
  • multivariate flags can have a payload per variant Backend
• Update decide endpoint/related functions to parse and return user-defined payloads

Server library Pending Example: https://github.com/PostHog/posthog-python/pull/81

• Add a get_feature_flag_payload function
  • Takes a flag key, distinct_id, and optionally a matched flag value
  • Attempts to evaluate locally first otherwise defers to decide endpoint result
• Add a get_all_flags_and_payloads
  • Attempt to retrieve all matching feature flag flags and payloads locally
  • Defer to decide endpoint if necessary
  • this should do the same thing as get_all_flags but include payloads now
• Update decide v=2 to decide v=3

WIP

• [x] Decide endpoint update (https://github.com/PostHog/posthog/pull/13623)
• [x] posthog-js-lite base implementation (https://github.com/PostHog/posthog-js-lite/pull/50)
• [x] posthog-node local evaluation based on posthog-js-lite implementation (https://github.com/PostHog/posthog-js-lite/pull/54)
• [x] UI/Frontend for accepting json payloads (https://github.com/PostHog/posthog/pull/13689)
• [x] Bootstrap (https://github.com/PostHog/posthog-js-lite/pull/59)

Problem 2

• Make sure feature flags are resilient, i.e. even if Posthog servers go down, or returns partial results, feature flags in libraries can keep working

Implementation

• Local evaluation requests: If we return a non-200 response, don't override existing flags.
• Decide requests: If we return a non-200 response, don't override existing flags. If we return a partial response, upsert flags. (see implmenetation details here)
• Timeouts: Don't let the library hang, have a 10s timeout for both requests above. (implementation)
• Null/empty check for personal API keys: Don't make requests to local_evaluation if the personalApiKey passed in is empty, null. See this link for context
• For a full implementation (a.k.a not just client library parts, see: https://github.com/PostHog/posthog/issues/13601 )

[liyiy]

Client libraries

• [ ] posthog-js: update here when this is done: https://posthoghelp.zendesk.com/agent/tickets/1492
  • [ ] https://github.com/PostHog/posthog-js/pull/511
• [x] posthog-js-lite
• [ ] React Native
• [ ] Flutter
• [x] iOS https://github.com/PostHog/posthog-ios/pull/37
• [ ] Android (@liyiy)

Server libraries

• [x] Node (@EDsCODE)
• [x] Python (@EDsCODE)
  • [x] https://github.com/PostHog/posthog-python/pull/81
  • [x] also fix: https://github.com/PostHog/posthog-python/issues/78
• [ ] Go (@liyiy)
• [x] Ruby (@liyiy) https://github.com/PostHog/posthog-ruby/pull/27
  • [x] also fix this alongside https://github.com/PostHog/posthog-ruby/issues/24
• [ ] Java
• [ ] PHP (@liyiy)
• [ ] Elixir
• [ ] Rust

[liyiy]

Technically resiliency + payloads is separate work but we're just rolling it out under v3 for one major upgrade right? It could be nice to make this super clear on what the work for v3 entails and what the timeline for stuff is because resiliency updates include caching server side stuff + there's client side stuff. And then there's JSON payloads which doesn't rely on any of that other than the versioning right?

And then we also started some library updates too so it looks like everything is in progress RN 😅 And I am unsure of where and what exactly I'm picking up.

[neilkakkar]

Not sure if you've read this which explains all this?: https://github.com/PostHog/meta/pull/74/files

We're rolling them together precisely so we don't have to touch all libraries 2x 😅

[liyiy]

Not sure if you've read this which explains all this?: https://github.com/PostHog/meta/pull/74/files

We're rolling them together precisely so we don't have to touch all libraries 2x 😅

I did and I agree with it, let's just reconvene in standup tomorrow lol 😅

[EDsCODE]

And then we also started some library updates too so it looks like everything is in progress RN 😅 And I am unsure of where and what exactly I'm picking up.

We're starting with critical path from the decide endpoint updates that need to happen and then posthog-js/posthog-core because we can get it in use for us first. All the library updates are separate tracks of work that can be done in parallel as long as it adheres to the details listed in the original post. Definitely hop into reviewing the decide endpoint changes but besides that, all the library updates are green field to pick up

As for resiliency library updates, there's this + anything else Neil may add but I wouldn't let that block you as it doesn't have to all be handled in one PR

[dmarticus]

closing because we for sure did this