Event must be a string

[mariusandra]

Changes

• Prevents storing random JSON blobs in the team.event_names array.
• Those random objects break the event search in the frontend
• Occurred with posthog-js pre-1.8.3 (fixed since), when calling posthog.capture({ object: 'bla' }).
• Happened for a user
• Both postgres and clickhouse error after the broken event is stored in event_names with something like:

# with clickhouse
raise TypeError(message)
TypeError: {'event': 'bla', 'properties': {'a': 'b'}} has type <class 'dict'>, but expected one of: (<class 'bytes'>, <class 'str'>)

• Because of that protobuf error I also check for bytes and not only str, but we could only check str here. I'm not sure what might come over the wire and if checking just str would break anything or not. I'm willing to change this, but might not be needed.
• Test added as well

Checklist

• All querysets/queries filter by Organization, by Team, and by User
• Django backend tests
• Jest frontend tests
• Cypress end-to-end tests

[timgl]

This won't be returned to the user submitting the event, it'll just show up in Sentry. If I think what I'd want for debugging purposes it'd be better if we just convert objects to strings (max 200 characters) so that I can at least see them come in and fix whatever happens, rather than have a silent failure.

[mariusandra]

sure, updated!

[mariusandra]

@timgl this is good for another look. I'd merge directly due to your approval, but some things changed:

• Since I'm locally using python 3.9, I had to upgrade mypy to get it to work, this required changing some unrelated types. Mainly request.user is now Union[AnonymousUser, User]. It required a tweak in decide.py and an # ignore in utils.py, which used a try/except block to catch the AnonymousUser.team error. There was some other issue with urls.py, which I seem to have fixed (tested locally, all urls still work like they should)
• I added a migration to update team.event_names in case it contains non-strings. I coded it in a very defensive way, making it only run if there's something to update and also only importing the calculation function if something indeed needs to be changed. This way if we ever move the imports around (e.g. delete the calculate_event_property_usage_for_team function due to some future situation), the migrations won't all suddenly just fail. I could have dispatched a background task as well, but somehow starting background jobs in migrations seems weirdly non-deterministic and I'd opt to avoid that.