blog: a percentage is not a rollout - #1436
Conversation
Adds a post on where fractional evaluation stops and rollout progression begins, and on what hooks can and cannot do about it. Signed-off-by: Santhosh Kumar Somarapu <somarapu.santhosh91@gmail.com>
✅ Deploy Preview for openfeature ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
Next review available in: 16 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds a blog article that distinguishes fractional flag evaluation from rollout orchestration and adds the article author’s profile to the author registry. ChangesEvaluation and Rollout Documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (2)
blog/2026-08-09-a-percentage-is-not-a-rollout.md (2)
151-161: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winDefine the portable field units and scope.
If this table is intended for interchange, define the units and range of
current_exposureandintended_target, such as a fraction in[0,1]or a percentage in[0,100]. Also state whether the record applies to a flag, environment, variant, or cohort. Without this contract, consumers can encode different meanings, and multi-variant rollout state remains ambiguous.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@blog/2026-08-09-a-percentage-is-not-a-rollout.md` around lines 151 - 161, Update the portable shape table to define the units and valid range for current_exposure and intended_target, using one consistent representation, and add the record’s scope so it explicitly identifies whether the rollout applies to a flag, environment, variant, or cohort. Clarify multi-variant applicability rather than leaving consumers to infer it.
129-132: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winAdd a privacy constraint to subject correlation.
OpenFeature defines
feature_flag.context.idas the evaluation subject identifier and falls back to the targeting key, so exposure telemetry can uniquely identify a subject. State that exposure telemetry must use a privacy-safe or pseudonymous identifier and follow retention and access controls, and avoid recommending raw user identifiers by default.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@blog/2026-08-09-a-percentage-is-not-a-rollout.md` around lines 129 - 132, Update the “Emit exposure, not blanket metric tags” guidance to require privacy-safe or pseudonymous subject correlation identifiers, rather than raw user identifiers by default. Reference the OpenFeature subject identifier semantics while requiring appropriate retention and access controls for exposure telemetry.Source: MCP tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@blog/2026-08-09-a-percentage-is-not-a-rollout.md`:
- Around line 44-45: In the sentence listing provider-specific choices, replace
the phrase “weights-as-relative-rather-than-absolute” with the clear noun phrase
“the use of relative rather than absolute weights,” leaving the surrounding
wording unchanged.
- Around line 93-95: Update the hook execution-order documentation in the
surrounding discussion of Requirement 4.4.2 to explicitly distinguish both
stages: document before hooks as API → Client → Invocation → Provider, and
after, error, and finally hooks as Provider → Invocation → Client → API,
including reverse registration order within each level.
- Around line 55-59: Update the description of OpenFeature’s Evaluation API in
the surrounding rollout discussion to state that it standardizes how
applications request and receive evaluation results, rather than standardizing
exposure decisions or allocation behavior. Preserve the distinction that
providers determine evaluation values and rollout progression remains outside
the API.
- Around line 129-132: Update the exposure-record recommendation in “Emit
exposure, not blanket metric tags” to make variant optional and reason
recommended rather than universally required, while retaining the flag key,
correlation identifier, and trace-enrichment guidance.
---
Nitpick comments:
In `@blog/2026-08-09-a-percentage-is-not-a-rollout.md`:
- Around line 151-161: Update the portable shape table to define the units and
valid range for current_exposure and intended_target, using one consistent
representation, and add the record’s scope so it explicitly identifies whether
the rollout applies to a flag, environment, variant, or cohort. Clarify
multi-variant applicability rather than leaving consumers to infer it.
- Around line 129-132: Update the “Emit exposure, not blanket metric tags”
guidance to require privacy-safe or pseudonymous subject correlation
identifiers, rather than raw user identifiers by default. Reference the
OpenFeature subject identifier semantics while requiring appropriate retention
and access controls for exposure telemetry.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ee4faa14-9ae1-433e-9dcd-aad1892c18ea
📒 Files selected for processing (2)
blog/2026-08-09-a-percentage-is-not-a-rollout.mdblog/authors.yml
Hook ordering was only half stated. before runs API, Client, Invocation, Provider, but after, error and finally run in reverse, Provider, Invocation, Client, API, and within each level in reverse registration order. Now says both. Removed an internal contradiction. The piece argued that conformant providers can bucket differently, then described the evaluation API as standardizing exposure decisions. It standardizes how applications request and receive evaluation results; allocation sits with providers and progression with control planes. Exposure-record fields now match appendix D rather than presenting all three as required: flag key required, variant conditionally required, reason recommended. Reworded weights-as-relative-rather-than-absolute. Signed-off-by: Santhosh Kumar Somarapu <somarapu.santhosh91@gmail.com>
1 participant
Adds a blog post on the boundary between what the evaluation API standardizes and what a control plane owns, and on where hooks stop being useful for rollout control.
What it argues
fractionaloperation picks murmur3, a seed convention, and relative weights, none of which are specification requirements, so a conformant second provider can put a different set of subjects in the exposed cohort at the same stated percentage.Specification accuracy
Every specification claim is cited inline and was checked against the spec repository rather than written from memory:
errorrunning for thebeforestage, flag resolution, or theafterstage (Requirement 4.3.7)finallyrunning afterbefore,afteranderror(Requirement 4.3.8)beforereturning evaluation context that is then merged (Requirements 4.3.4 and 4.3.5)trackno-opping when the provider does not implement tracking (Requirement 6.1.4)finally, per appendix D on observabilityWhere the post makes a claim about flagd, it links flagd's own fractional-operation documentation.
Housekeeping
Adds an
authors.ymlentry. Post follows the existing convention:blog/YYYY-MM-DD-slug.md, front matter with title, description, date, categories, slug and authors, and a<!--truncate-->marker after the intro. Commit is signed off.Happy to cut the closing proposal section if it reads as out of scope for the blog, or to adjust the framing anywhere it misrepresents the project's intent.