Repository navigation
feat(feature-flags): Align rule and target management with API contracts - #1719
stanleyphu wants to merge 2 commits into
Conversation
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const { data } = await this.workos.post<FlagTargetMembershipResponse>( | ||
| '/flag_targets', | ||
| { rule_id: options.ruleId, target_id: options.targetId }, | ||
| ); |
There was a problem hiding this comment.
The current API rejects this POST /flag_targets payload: it does not yet accept rule_id and requires flag_slug and target_type. Direct calls to createFlagTarget therefore return a 400. createRuleWithTargets creates the rule first, then fails on its first membership and leaves an empty rule to reconcile. This needs the AUTH-7084 API deployment and a successful end-to-end check before release.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/feature-flags/feature-flags.ts
Line: 80-83
Comment:
**Membership creation fails**
The current API rejects this `POST /flag_targets` payload: it does not yet accept `rule_id` and requires `flag_slug` and `target_type`. Direct calls to `createFlagTarget` therefore return a 400. `createRuleWithTargets` creates the rule first, then fails on its first membership and leaves an empty rule to reconcile. This needs the AUTH-7084 API deployment and a successful end-to-end check before release.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
stanleyphu
changed the title
|
@greptileai review Updated at |
2 participants
Why
I hit a 400 while testing rule authoring with the flags app: the SDK sent
feature_flag, while the API requiresflag_slug. Rule creation, listing, and the convenience helper now acceptflagSlugand send the correct field. Target lookup and filtered pagination handle both API contracts: memberships exposeruleId; legacy targets exposevalueandvalueType.Membership creation sends only
rule_idandtarget_id. The helper retains the created rule and confirmed memberships after a later failure, and existing target aliases remain available.Release prerequisite: deploy the target membership API contract tested at revision
7a0095af09e7. Enablefeature-flags-targeting-rulesand turn offfeature-flags-legacy-target-contractfor membership authoring; the legacy contract takes precedence while enabled. Before enabling authoring, verify v2-capable runtime SDKs andrule-based-flag-evaluationin each affected environment.Not covered by CI
7a0095af09e7, without request translation: rule CRUD and evaluation-order pagination, membership lookup and combined filters, ascending/descending cursor pagination, duplicate/conflicting targets, helper success, partial failure, recovery, and sibling preservation all passed.trueand v2false; reversing the rules changes the live decision totrue.value/valueTypewithoutruleId. Membership-only creation returns 400 in this mode, and the helper reports its retained empty rule.Repeat the successful membership check against the deployed API before release.
Proof
The updated SDK sent this request directly to the local API:
It then sent
POST /flag_targetswith{"rule_id":"flag_rule_01M4BVRT8FQ3N94ZPEVQX31SFZ","target_id":"user_01KM490ND31XPKGTYFAC9APFJ4"}. The API returned HTTP 201 with membershipflag_target_01M4BVRTACYNBCS05B5N3W7Y6W, the samerule_id, and novalue/value_typefields. Lookup and filtered listing returned the same membership.A later missing organization returned 404:
CreateRuleWithTargetsErrorretained ruleflag_rule_01M4BVRZBSC0MCY1ASQTC6230Qand its one confirmed membership; the next target was not attempted. Adding that next target to the retained rule succeeded.Response excerpts omit unchanged fields. These IDs belonged to disposable local fixtures that have been removed.
Fixes AUTH-7099