posthog icon indicating copy to clipboard operation
posthog copied to clipboard

Wrong property type displayed in the live events list

Open mariusandra opened this issue 3 years ago • 4 comments

Bug description

There is a subtle uncommunicated discrepancy with property types on the live events page.

How to reproduce

I sent this event locally:

posthog.capture('test event', { $browser: 123, $browser_version: 'not a string' })

and took these screenshots of it:

image image

The $browser and $browser_version properties have their types mixed up in the table view. That's because next to each property we show the expected type, as stored in the PropertyDefinition model. In this case, the actual type happened to be different.

This feels wrong. Should we just show the type as it is currently in transit, or as it is in the property definition? Should we alert the user with something a cryptic hacker message like "this property is not the same type as its definition"?

The type in the property definition model is used primarily in various filters. E.g. we show math aggregations for only event properties that have numeric data.

I see that in the data management pages we don't even show the event types 🤔

image

Is there any reason to keep the behaviour as is?

Environment

  • [ ] PostHog Cloud
  • [ ] self-hosted PostHog, version/commit: please provide

Additional context

This came out of work on https://github.com/PostHog/posthog/issues/8257, and out of earlier work to detect and better show datetimes. That's when knowledge of the type of property is useful...

Thank you for your bug report – we love squashing them!

mariusandra avatar Aug 23 '22 20:08 mariusandra

If the property $browser is a string and you send 123 is the string label incorrect or the value?

I don't think the answer is going to be the same in every case.

You can now edit the property definition type.

So I think that highlighting where you are receiving properties that don't match the detected definition and letting you either change the type or go fix your code that is sending 123 as $browser (depending on which is right for you)

Communicating how to fix the type might be hard. Maybe we prompt with what type makes most sense for queries

pauldambra avatar Aug 23 '22 20:08 pauldambra

I see that in the data management pages we don't even show the event types 🤔

Yeah, we should fix that. If you're licensed and click through to edit on that view then you can change the type... maybe a spot where we could up-sell if we had the type visible on the view page

pauldambra avatar Aug 23 '22 20:08 pauldambra

Maybe compound labels would be helpful here? We could show something like expected:string received:number?

clarkus avatar Aug 24 '22 16:08 clarkus

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

posthog-bot avatar Aug 26 '24 07:08 posthog-bot

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.

posthog-bot avatar Sep 09 '24 07:09 posthog-bot