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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/support feature flags #12
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks a lot for this! Appreciate you submitting it upstream.
Left one inline comment, but overall looking good. Some thoughts:
- I'm happy to merge this with only
LibCurl
support - Some tests that mock the endpoint response and verify that the code handles the response appropriately should be enough.
- This implementation appears correct and is an improvement over what we currently have (no feature flags), so it should be valid to merge. However, I'd appreciate if you could consider adding support for
is_simple_flag
(see Python lib). I'm adding feature flags toposthog-node
this week and will write a spec for implementing flags in other libraries. Essentially, foris_simple_flag
, we use a Personal API Key to poll for flags and if they're "simple" (only rollout percentage, no filters), we calculate them locally for speed. This can definitely be a separate PR and I'm happy to help.
Node is done and the "spec" is written @imhmdb are you planning on making the changes here? totally understand if not, just checking |
of course, I'll give it a shot today and see how it goes. |
I think this only needs to have tests fixed with mocks |
Done fixing tests with the mocked response of simple flags. |
Awesome, thanks a lot! I'll give this a review latest by tomorrow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Follows the spec perfectly for the most part (see below). I'm about to test it locally and will report back.
Thanks again for doing this.
One final comment that just came to mind: should we also error out if people chose not to use libcurl and they try to use feature flags?
private function loadFeatureFlags(): void | ||
{ | ||
$response = $this->httpClient->sendRequest( | ||
'/api/feature_flag', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've made a change since you last edited this, so this should now be /api/feature_flag?token=project_api_key_here
.
No way you could have known though!
$this->featureFlags = []; | ||
} | ||
|
||
$this->featureFlags = $responseBody['results']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another change we made is that this should filter by active flags.
The active
property is in $responseBody['results'][i]['active']
{ | ||
$this->assertIsArray(PostHog::fetchEnabledFeatureFlags('user-id')); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we add a test for isSimpleFlagEnabled
?
Flag of key a
with distinct id b
should be on for rollout percentage 42
but off for rollout percentage 40
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having tried this and re-read the code - there are a few issues. First is a POST request to api/feature_flag
. Second is that we're missing a poller. We shouldn't load feature flags once, we should load them regularly at an interval in the background.
|
||
private function loadFeatureFlags(): void | ||
{ | ||
$response = $this->httpClient->sendRequest( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so I tried this locally and it didn't work. I suspect this is a potential problem. We're sending a POST request here, when it should actually be a GET request.
Hi, @yakkomajuri Regarding the libcurl error, when I reimplemented according to spec I moved the feature flags from libcurl consumer into the client, not sure if you mean ext-curl and not the libcurl-posthog-consumer here, cuz that would be a valid case to error on. Regarding the poller, I wasn't sure how can I keep polling at an interval when php doesn't supports threads or pools, have this poller been implemented in a php-like client that I can take insights from? Regarding the errors on the POST request, this sure is weird As I made sure the tests were working on my production environment keys instead of debug ones, but maybe the tests were also broken 😂 I'll sure take a second look and try to debug and fix the addressed issues. Side note: I just got out of surgery so it might take me a week or two of recovery until I can get my hands on this thing again, just letting you guys know. |
I could also be at fault here - not a PHP dev, so if anything I say sounds crazy, it probably is. Also, get better! No rush! I might also pick this up if I get the time. Thanks again for all your work @imhmdb |
Closing in favor of #18 @posthog-bot please add @imhmdb for code |
I've put up a pull request to add @imhmdb! 🎉 |
@posthog-bot please add @imhmdb for code |
@posthog-bot please add @imhmdb for code |
I've put up a pull request to add @imhmdb! 🎉 |
Follows spec for implementing feature flags support:
https://github.com/PostHog/posthog.com/pull/1455/files