Skip to content

feat: Count override-affected evaluations separately and send no individual events for them - #219

Draft
kinyoklion wants to merge 1 commit into
feat/overridesfrom
rlamb/overrides-java-internal-events-marker
Draft

kinyoklion wants to merge 1 commit into
feat/overridesfrom
rlamb/overrides-java-internal-events-marker

Conversation

@kinyoklion

Copy link
Copy Markdown
Member

Summary

The OVERRIDE specification marks an evaluation as override-affected when any definition it read came from the SDK's override store. Such an evaluation appears in summary events only: it produces no individual feature event and no debug event, whatever the flag's configuration requests, and it is counted in a separate summary counter that carries an overrideAffected marker, so override-affected and ordinary evaluations of the same flag, variation, and version are never collapsed together.

  • Event.FeatureRequest carries the marking as a boolean that the SDK sets from its evaluation result. The existing constructors keep working and leave it false; toDebugEvent() keeps the value.
  • DefaultEventProcessor keys individual feature event and debug event emission on the marking. Index events and summaries are unchanged.
  • EventSummarizer keeps a second set of counters per flag for marked evaluations, created on first use so unmarked flags pay nothing. EventOutputFormatter writes overrideAffected: true only on those counters, the same way the unknown marker is written.
  • EventSummarizerInterface gains the marker parameter and keeps the previous signature as a default method that delegates with false.

Flag overrides are currently experimental and subject to change. The server SDK change that sets the marking depends on the release of this package.

…vidual events for them

The OVERRIDE specification marks an evaluation as override-affected when
any definition it read came from the SDK's override store. Such an
evaluation appears in summary events only: it produces no individual
feature event and no debug event, whatever the flag's configuration
requests, and it is counted in a separate summary counter that carries
an overrideAffected marker so that override-affected and ordinary
evaluations of the same flag, variation, and version are never collapsed
together.

Event.FeatureRequest carries the marking as a boolean that the SDK sets
from its evaluation result. The existing constructors keep working and
leave it false. DefaultEventProcessor keys individual event and debug
event emission on it. EventSummarizer keeps a second set of counters per
flag for marked evaluations, created on first use, and the output
formatter writes overrideAffected only on those counters, like the
unknown marker. EventSummarizerInterface gains the marker parameter and
keeps the previous signature as a default method.

Flag overrides are currently experimental and subject to change.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant