Event type for feature flag operations #297

Activity

1. xibz commented on Jul 28, 2026

   

   xibz

   on Jul 28, 2026

   Contributor

   More actions

   @mattgogerly - is there any updates on this?
2. mattgogerly commented on Jul 29, 2026

   

   mattgogerly

   on Jul 29, 2026

   Author

   More actions

   Not at the moment unfortunately, I had to pivot onto a different project.
3. ahmedbektic commented on Sep 17, 2026

   

   ahmedbektic

   on Sep 17, 2026

   More actions

   @xibz @mattgogerly I would like to work on this
4. xibz commented on Sep 17, 2026

   

   xibz

   on Sep 17, 2026

   Contributor

   More actions

   @ahmedbektic please take a crack at it :). What may be a good idea is lay out what facts we want to signal then once we outline those, you can create the schemas
5. ahmedbektic commented on Sep 19, 2026

   

   ahmedbektic

   on Sep 19, 2026

   More actions

   I think three actions could be: create/change/delete flag.

   Each event should identify:

   • The flag
   • The environment or project it belongs to
   • What action happened
   • The resulting state

   For a change, the following information could be recorded:

   • The flag was enabled or disabled
   • The default value changed
   • The rollout percentage changed
   • The targeting configuration changed
   • A dependency on another flag changed

   Would you prefer

   1. An event be sent for every saved edit, or only when a change becomes active?
   2. For rollout changes, should old and new percentages be reported, or only report that there was a change?
   3. Individual flag evaluations, user identities, ... etc be included or no?
   4. There exist an audit record so that users can investigate the changes or no?

   I am more than happy to adjust these facts or give more specific details on the facts @xibz
6. xibz commented on Sep 30, 2026

   

   xibz

   on Sep 30, 2026

   Last edited by xibz

   Contributor

   More actions

   @ahmedbektic thanks for taking the time to think about this. I really like the questions and the outline. I think this is looking good. Let's get some sample models of what the model would look like.

   What is the event's subject?
   What are the predicates?

   An event be sent for every saved edit, or only when a change becomes active?

   Only when active is more aligned to CDEvents

   For rollout changes, should old and new percentages be reported, or only report that there was a change?

   I think this is conflating feature flag with release metadata. feature flag events are probably the wrong event to hold it.

   Individual flag evaluations, user identities, ... etc be included or no?

   For individual flag evaluations we could model this in a few ways, a link to the actual feature flag change, e.g., github, some reference link of a feature flag service. The other option is the raw value for evaluation. We probably dont want to model the raw evaluated values.

   user identities could be included, but what would it mean? Who changed it? deployed it? or what?

   There exist an audit record so that users can investigate the changes or no?

   How would this be modeled?
7. ahmedbektic commented on Oct 2, 2026

   

   ahmedbektic

   on Oct 2, 2026

   More actions

   @xibz

   Here are my thoughts:

   What is the event's subject?
   What are the predicates?

   I propose featureFlagConfiguration as the subject because each occurrence concerns a flag’s effective configuration in one environment.

   The predicates would be:

   • created: the first configuration becomes effective in the environment.
   • modified: a subsequent configuration becomes effective.
   • deleted: the configuration is removed from the environment.

   The initial content would contain:

   • environment: required environment reference.
   • enabled: resulting state for created and modified.
   • uri: optional link to the flag in the provider.
   • user: optional actor that made the configuration effective.

   The examples below are subject excerpts. They assume that subject.source identifies the originating feature-flag provider, project, and environment and differs from the event producer’s context.source.

   Created

   {
     "id": "checkout-redesign",
     "source": "https://flags.example/projects/storefront/environments/production",
     "content": {
       "environment": {
         "id": "production"
       },
       "enabled": false,
       "uri": "https://flags.example/projects/storefront/flags/checkout-redesign",
       "user": "release-automation"
     }
   }

   Modified

   {
     "id": "checkout-redesign",
     "source": "https://flags.example/projects/storefront/environments/production",
     "content": {
       "environment": {
         "id": "production"
       },
       "enabled": true,
       "uri": "https://flags.example/projects/storefront/flags/checkout-redesign",
       "user": "release-automation"
     }
   }

   Deleted

   {
     "id": "checkout-redesign",
     "source": "https://flags.example/projects/storefront/environments/production",
     "content": {
       "environment": {
         "id": "production"
       },
       "user": "release-automation"
     }
   }

   enabled is omitted from deleted because there is no resulting configuration. The provider URI is also omitted because it may no longer resolve.

   Only when active is more aligned to CDEvents

   Agreed. Events would only be emitted when a configuration becomes effective, not when a draft is saved. “Effective” is separate from “enabled”: an effective configuration may have "enabled": false.

   I think this is conflating feature flag with release metadata. Feature flag events are probably the wrong event to hold it.

   Agreed. I would leave rollout metadata out of the initial model.

   For individual flag evaluations we could model this in a few ways...

   I agree that an optional link to the relevant change, such as a GitHub change or a reference in the feature-flag service, would be best.

   User identities could be included, but what would it mean?

   Here, user would mean the human or automation that caused the configuration to become effective. It would not identify an evaluated user or necessarily the person who deployed the application.

   How would an audit record so that users can investigate the changes be modeled?

   I’m not sure yet what the best way to model this would be. I would prefer to leave this open for now.