Skip to content

Usage events send event_key for deduping event emission retries for the same event - #69610

Open
charlestp wants to merge 2 commits into
charles/client-kind-user-agentfrom
charles/prehog-event-key
Open

Usage events send event_key for deduping event emission retries for the same event#69610
charlestp wants to merge 2 commits into
charles/client-kind-user-agentfrom
charles/prehog-event-key

Conversation

@charlestp

Copy link
Copy Markdown
Contributor

Another fix while implementing DiscoveryConfigChangeEvent. Usage event submission has retry behavior, but no way to dedupe if multiple event submissions end up going through for the same event. This adds an event_key to use for deduplication on the backend.

Manual Test Plan

Test Environment

Local build.

Test Cases

  • Check that event_key is filled when making prehog requests.

@charlestp charlestp added no-changelog Indicates that a PR does not require a changelog entry backport/branch/v18 labels Aug 12, 2026
@github-actions
github-actions Bot requested review from eriktate and jakealti August 12, 2026 18:33
@charlestp
charlestp force-pushed the charles/prehog-event-key branch from c36e2fc to 579692e Compare August 13, 2026 05:27
@charlestp
charlestp changed the base branch from master to charles/client-kind-user-agent August 13, 2026 05:28
Comment thread lib/usagereporter/teleport/usagereporter.go
Comment thread lib/usagereporter/teleport/usagereporter_test.go Outdated
Comment on lines +2206 to +2210
// event_key is a UUID distinguishing one underlying event occurrence,
// allowing consumers to deduplicate resubmissions.
//
// PostHog property: tp.event_key
string event_key = 128;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this in sync with cloud's version?
https://github.com/gravitational/cloud/blob/f2e2758344d2547ace065d5d699be0942f448e6b/build/prehog/proto/prehog/v1alpha/teleport.proto#L2202

Can you link the PR here to ensure we keep both protos in sync?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet. To try to avoid iterations, my plan is to get teleport ready first, then PR cloud, then merge.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have both changes approved before merging any.
Let's say that we change teleport emitter but not the receiver part.
And now we try to change the receiver, but cloud's PR receives some back and forth comments and we end up with a different name.

We would need to get back here and change things again.

From
https://app.notion.com/p/goteleport/Implementing-Usage-Events-Prehog-2dcfdd3830be809f85a4c1e11a272d76

The process involves updating the Prehog service to handle the new event type, configuring the data warehouse to store the event data, and finally implementing the event emission in Teleport's codebase.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm aware, I wrote that line of the guide 😆

I'm going in reverse order because the implementation in teleport is much more significant than the cloud side. But I'll write my process into an RFD so this doesn't cause more PR churn.

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

Labels

backport/branch/v18 no-changelog Indicates that a PR does not require a changelog entry size/sm

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants