[discourse] More segment information uppon rollout deletion

[markphelps]

Originally posted by crossy-l on Discourse

Currently when a rollout is deleted an audit log like this is created:

{
  "version": "0.2",
  "type": "rollout",
  "action": "deleted",
  "status": "success",
  "metadata": {
    "actor": {
      "authentication": "none",
      "ip": "::1"
    }
  },
  "payload": {
    "flag_key": "test",
    "id": "7b4b0aa1-0f6e-42e6-8dfd-efd9def7fc5b",
    "namespace_key": "default"
  },
  "timestamp": "2025-06-04T13:36:29+02:00"
}

Now we use the audit logs to monitor changes made and also provide a diff between the current state and the previous state. Now as far as I am aware there is no easy way to get the data corresponding to the “id” field and it would be much easier if the rollout deletion would carry at least information like this:

{
  "version": "0.2",
  "type": "rollout",
  "action": "deleted",
  "status": "success",
  "metadata": {
    "actor": {
      "authentication": "none",
      "ip": "::1"
    }
  },
  "payload": {
    "rank": 1,
    "segment": {
      "key": "numero-dueos"   # <--- Information about the deleted segment
    }
  },
  "timestamp": "2025-06-04T13:36:29+02:00"
}

Basically like the audit log for rollout creation or updates.

ToDo:

• Add information about the segment to the audit log uppon rollout deletion

[markphelps]

Reply from erka on Discourse:

Hey @crossy-l

I’d like to include the segment data in the delete audit record, but that isn’t straightforward with the current audit architecture.

Rules for variant flags include their id in the audit log for create and update actions.

I suggest doing the same for rollouts by including their id as well.

While it’s not a perfect solution, having the rollout ID will make it possible to list all related audit records and provide a clearer picture of the changes over time.

Will it work for you?

[markphelps]

Reply from crossy-l on Discourse:

Hey erka, thanks for looking into this.

So I am not sure what you mean by ‘Rules for variant flags include their id in the audit log’, as when creating a rule for a variant flag that has a Segment rule:created doesn’t produce any audit logs. Same with updates.

On an unrelated note:

I cannot seem to get any audit logs for updating a variant flags variants. variant:updated doesn’t seem to get handled by the eventPairChecker. Is this intended behaviour? Am I doing something wrong?

In order to compare old to new we use a flipt export of the previous state.

So anything I can use to find the previous data inside of the flipt export would be incredibly useful.

The id’s aren’t listed in the export though.

[markphelps]

Reply from erka on Discourse:

@crossy-l

when you start the Flipt with debug log level, it shows the list of events enabled for specific sink type. For example,

 DEBUG   audit sinks enabled     {"server": "grpc", "sinks": ["log"], "buffer capacity": 2, "flush period": "2m0s", "events": ["token:deleted", "token:updated", "variant:created", "variant:updated", "constraint:updated", "distribution:created", "distribution:updated", "rollout:created", "rollout:updated", "rule:updated", "token:created", "constraint:created", "flag:created", "flag:deleted", "segment:updated", "variant:deleted", "distribution:deleted", "flag:updated", "namespace:deleted", "rollout:deleted", "rule:created", "rule:deleted", "segment:created", "segment:deleted", "constraint:deleted", "namespace:created", "namespace:updated"]}

With latest Flipt, when rule/rollout is created or update it will include the id in the payload.

In my setup, like this

{"T":"...","M":"AUDIT","version":"0.2","type":"rollout","action":"created","status":"success","metadata":{"actor":{"authentication":"none","ip":"::1"}},"payload":{"description":"","flag_key":"test-boolean","id":"08c233f0-0b62-4490-9adf-9ae9536a5b0b","namespace_key":"default","rank":3,"segment":{"key":"Test-Segment","value":true}},"timestamp":"..."}

If I delete that rollout, I will get the record like

{"T":"...","M":"AUDIT","version":"0.2","type":"rollout","action":"deleted","status":"success","metadata":{"actor":{"authentication":"none","ip":"::1"}},"payload":{"flag_key":"test-boolean","id":"08c233f0-0b62-4490-9adf-9ae9536a5b0b","namespace_key":"default"},"timestamp":"..."}                                                                                                      

Both of them has id 08c233f0-0b62-4490-9adf-9ae9536a5b0b and could be connected.

What sink type do you use in your configuration?

[dosubot[bot]]

The sink type in your configuration determines where audit logs are sent (for example, "log" for standard logging). You can see the enabled sink types and events by starting Flipt with debug log level, as shown in your example. The audit log records for rollouts can be connected using the shared "id" field—this lets you correlate creation, update, and deletion events for the same rollout.

Regarding segment data: there was a confirmed bug where segment details were missing from rollout audit logs, but a fix has been developed to include more comprehensive segment information, including the segment operator, in the audit logs for rollouts. This should improve your ability to track changes and correlate events using the audit logs and the "id" field. For variant flags and rollouts, the audit log behavior is handled transparently by the gRPC middleware, which ensures the "id" is always included and segment data is serialized when available, depending on the rollout type. If you need to check or change your sink type, look for the "sinks" field in your Flipt configuration or logs—there isn't public documentation on configuring this, but the debug output will show what's active for your instance.
Reference: bug and fix for missing segment data

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[crossy-l]

@erka Thanks for your reply.

I have now setup my sink correctly to receive all kinds of audit logs:
DEBUG audit sinks enabled {"server": "grpc", "sinks": ["log"], "buffer capacity": 2, "flush period": "2m0s", "events": ["rollout:created", "rollout:deleted", "segment:deleted", "distribution:deleted", "flag:created", "namespace:created", "rule:created", "rule:updated", "token:deleted", "variant:created", "constraint:deleted", "rollout:updated", "rule:deleted", "segment:updated", "token:created", "variant:updated", "constraint:created", "distribution:created", "namespace:updated", "segment:created", "token:updated", "variant:deleted", "constraint:updated", "distribution:updated", "flag:deleted", "flag:updated", "namespace:deleted"]}

This is my audit config:

audit:
  events:
    - constraint:*
    - distribution:*
    - flag:*
    - namespace:*
    - rollout:*
    - rule:*
    - segment:*
    - token:*
    - variant:*
  sinks:
    log:
      enabled: true              
      encoding: json             
      file: ./bin/log/audit.log 

Or you just emit all the configs:

audit:
  sinks:
    log:
      enabled: true              
      encoding: json             
      file: ./bin/log/audit.log 

This works and I get the logs that are expected. But my issue still stands, even if I have the ids, how can I get the previous state of that object? The webhook is an isolated runner that right now doesn't perform any web requests (the flipt export is passed), so it's only got the current audit log.
What can I do to get the previous object in the case of Rollouts? If I were to perform some kind of request using the id, then that would presumably already return the new deleted state?
Am I missing some easy solution?

Sadly the flipt export (the one you get with ./bin/flipt export) doesn't have any mention of these Rollout ids, if they were included in the export, then that would also be a solution.

The only other idea I got right now, is to build some sort of audit log cache, which I can then look up the previous audit state for an object (this feels like overkill and introduces a lot of complexity).

[erka]

I understand your point. I also wish the delete API calls returned the deleted object — it would make this much easier to handle.
I’ll look into alternative ways to implement what you're asking for.

[erka]

@crossy-l I have done some work around and it's available in nightly build.

docker pull ghcr.io/flipt-io/flipt:v1.58.6-nightly

If you can please give it a try and tell us if that resolves your issues.

[crossy-l]

Yes, this resolves the issue and works exactly as expected. Thank you very much!