[Flags] Clarify behavior around fallback values - #219
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Co-authored-by: efahk <37164746+efahk@users.noreply.github.com>
russell-loube-mixpanel
left a comment
russell-loube-mixpanel
left a comment
There was a problem hiding this comment.
LGTM, some nits
| - **Variants** — experience labels (e.g., `control`, `A`, `B`). | ||
| - **Variant Splits** — allocation across variants (e.g., 90%/10%). | ||
| - **Fallback Value** — variant to use when an assignment is unavailable. | ||
| - **Fallback Value** — the value your app supplies at call time (e.g., to `get_variant_value`) that is used whenever the SDK does not return an assignment. Treat this as the default, control experience for your rollout that's served to a user who has not received an assignment. Reasons may include the user being outside the rollout %, excluded by targeting filters, not having a persisted sticky variant or client-side assignment, or feature flag API call failure. |
There was a problem hiding this comment.
When a previously assigned user is later excluded by a rollout-percentage or targeting change, a sticky or persisted client-side assignment can continue serving the prior variant, while this definition presents those exclusions as reasons the fallback is served. Developers can therefore expect the default experience while affected users continue receiving their previous variant.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
4 participants
No description provided.