feat(posthog-rs): enable uuid setting on capture events#70
Conversation
eli-r-ph
left a comment
eli-r-ph
left a comment
There was a problem hiding this comment.
The behavior we want here is, any event without a UUID set by the end user should have a random one generated and applied to the event prior to submission. As long as every event submitted goes out with a UUID one way or another, we can deduplicate properly on the backend
@eli-r-ph i was under the assumption that is no uuid is included in the event (which was the case for all events going through this sdk i think) - capture would generate one. is that not the case? or is that more for "this is how we'd actually like the sdk to behave"? |
|
@z0br0wn yes that's right - we have a fallback to generate UUID in capture but this causes event duplication in the backend when the SDK retries sending batches of events where some or all of the prev batch was ingested successfully - the repeat events all get fresh UUIDs in that case. Ideally we want the SDK to set missing UUIDs just once prior to submission so they don't change across any retries or app pauses |
|
@eli-r-ph ah i see! so is the ask for this pr to basically not make the uuid on event creation optional, and default to generating one (instead of passing through none)? |
| /// See the [PostHog documentation](https://posthog.com/docs/data/events) | ||
| /// for a detailed explanation of PostHog Events. | ||
| #[derive(Serialize, Debug, PartialEq, Eq)] | ||
| #[derive(Serialize, Clone, Debug, PartialEq, Eq)] |
There was a problem hiding this comment.
You added Clone here, but I don't see it being used. We should remove it? Cloning large data objects is not great
There was a problem hiding this comment.
ah sorry, i can break that out into a separate pr. clone is needed for the retry logic added in PostHog/posthog@71d7c0e
z0br0wn
force-pushed
the
zbrown/posthog-rs-set-event-uuid
branch
from
9675e70 to
bd72d0f
Compare
4 participants
this is change 3 of 3 for updating posthog-rs to be able to support the batch import worker.
currently there is no way to set a uuid on events upon creation. batch import worker, in some cases, will create a deterministic uuid for downstream deduping / better attempt at exactly once delivered. this change will allow us to thread a uuid through when desired.