Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(feature-flags): v3 json payloads #13623

Merged
merged 14 commits into from
Jan 17, 2023
Merged

Conversation

EDsCODE
Copy link
Member

@EDsCODE EDsCODE commented Jan 10, 2023

Problem

  • accept JSON payloads on all flags
  • feature flag filters can now parse payloads for boolean values
  • feature flag filters variants can now parse payload per variant
  • decide endpoint v=3 will return a new key featureFlagPayloads that returns a dictionary of matched keys to payload

Changes

馃憠 Stay up-to-date with PostHog coding conventions for a smoother review.

How did you test this code?

@posthog-bot
Copy link
Contributor

Hey @EDsCODE! 馃憢
This pull request seems to contain no description. Please add useful context, rationale, and/or any other information that will help make sense of this change now and in the distant Mars-based future.

@EDsCODE EDsCODE marked this pull request as ready for review January 11, 2023 20:10
@@ -130,12 +138,18 @@ def get_filters(self):
else:
# :TRICKY: Keep this backwards compatible.
# We don't want to migrate to avoid /decide endpoint downtime until this code has been deployed
return {
response = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

You don't need to add this, since it's for the backwards compatible case. Makes it more confusing 馃槄 .

This is for the case where the groups key is not in filters, and there's a direct properties key instead. There's no way for the payload to be here.

We might be able to remove this completely, depending on if any old clients remain.

Copy link
Member Author

Choose a reason for hiding this comment

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

There's a related failing test here. Checking again

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Collaborator

@neilkakkar neilkakkar left a comment

Choose a reason for hiding this comment

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

pending the two comments, looks good to me!

@neilkakkar
Copy link
Collaborator

re: failing test, the problem is you're using the old way to create flags (direct property key), with payloads, which should be impossible in the new UI, since we always use {"groups": []} now

@EDsCODE
Copy link
Member Author

EDsCODE commented Jan 16, 2023

Yeah got it. The backwards compatible code is so hectic

Copy link
Collaborator

@neilkakkar neilkakkar left a comment

Choose a reason for hiding this comment

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

2 nits okay for followup: ebafa3f#comments

@neilkakkar neilkakkar merged commit 9445c2c into master Jan 17, 2023
@neilkakkar neilkakkar deleted the feature-flag-v3-types-2 branch January 17, 2023 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants