feat(flags): support mixed targeting in local evaluation#3474
Merged
patricio-posthog merged 2 commits intomainfrom Apr 30, 2026
Merged
feat(flags): support mixed targeting in local evaluation#3474patricio-posthog merged 2 commits intomainfrom
patricio-posthog merged 2 commits intomainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Contributor
|
Size Change: +2.52 kB (+0.04%) Total Size: 6.99 MB
ℹ️ View Unchanged
|
Contributor
Prompt To Fix All With AIThis is a comment left during a code review.
Path: packages/node/src/__tests__/feature-flags.spec.ts
Line: 6821-6862
Comment:
**Rollout bucketing test doesn't verify its claimed behaviour**
The test is titled "rollout uses group bucketing for group conditions and distinct_id for person conditions", but `rollout_percentage: 100` means every hash passes regardless of which key is used for bucketing — so the test never actually distinguishes between group-key and distinct_id hashing.
Per the simplicity rule "Expresses every idea that we need to express", the test should use a sub-100% rollout with pre-computed hash values (e.g., find a `(flag.key, group_key)` pair whose hash is ≤ threshold while the `(flag.key, distinct_id)` pair is above it) so that the choice of bucketing value is observable. Without this, the test only confirms that local evaluation completes, not that the correct bucketing key is selected.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: packages/node/src/__tests__/feature-flags.spec.ts
Line: 6763-6818
Comment:
**Standalone `it` tests could be folded into the parameterised suite**
The two standalone `it` blocks below the `it.each` suite ("only group conditions, no groups passed" and the rollout test) cover scenarios that could be expressed as additional entries in the existing parameterised table. The team convention is to prefer parameterised tests, and the `it.each` fixture already supports varied `options` and `expected` values; the `onlyGroupFlag` variant would just need a second `localFlags` shape — which could be handled by adding an optional `localFlags` field to the table row or by splitting into two `it.each` blocks.
**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "feat(flags): support mixed targeting in ..." | Re-trigger Greptile |
marandaneto
reviewed
Apr 27, 2026
marandaneto
approved these changes
Apr 27, 2026
dmarticus
approved these changes
Apr 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Feature flags with "mixed targeting" (the
feature-flag-mixed-targetingbeta) allow different condition sets within a single flag to target different aggregation levels — some targeting users/persons, others targeting groups.The SDK only reads
aggregation_group_type_indexat the flag level. For mixed flags this isnull, so the SDK treats all conditions as person-targeted. Group conditions fail property matching and the SDK falls back to a server-side HTTP call.This breaks customers using flags in environments that cannot make HTTP calls (e.g., Temporal workflows).
Changes
Updated
matchFeatureFlagPropertiesto resolve aggregation per condition when a condition sets its ownaggregation_group_type_indexthat differs from the flag level. Each condition uses the correct properties and bucketing value for its aggregation type. Backwards compatible with existing pure person and pure group flags.Ports posthog-python#523 to posthog-node.
Release info Sub-libraries affected
Libraries affected
Checklist
If releasing new changes
pnpm changesetto generate a changeset file