Move from processing '$elements' to '$elements_chain'

[davemurphysf]

👋 Hello!

We recently merged a change in the posthog-js client to process the list autocaptured elements as a string, rather than an object. We noticed in your plugin that you are using $elements, and wanted to give you a heads up that you will need to update your code to use $elements_chain instead.

Right now, this change is behind a flag, and only internal Posthog traffic is using $elements_chain. Our plan is to expand this usage over the next couple of weeks, but we didn't want to break your plugin :-).

Let me know if you have any questions!

[andrewm4894]

@Ancairon this might break the Netdata PostHog plugin I think.

@davemurphysf what might be a good way for us to test this, is there some way to pass/use the flag on some feature branch we could make here and adapt our tests for?

[davemurphysf]

I can turn on the flag for a dev project if you give me the project ID (located at the bottom of the page on https://app.posthog.com/settings/project-details)

[hugovalente-pm]

hi @davemurphysf , have one doubt since we have multiple projects for each of our environments (Testing, Staging and PROD) and one for a specific component which is the Agent I will share the full list below

• PROD 7139
• Testing 7629
• Staging 7628
• Agent 7627

[davemurphysf]

Hey @hugovalente-pm / @andrewm4894, I enabled this behavior for both your Testing (7629) and Staging (7628) teams. You'll need to use version > 1.92.0 of posthog-js for the behavior to light up

[Ancairon]

@andrewm4894 how would we go about this? Is it a change in https://github.com/netdata/posthog-netdata-event-processing/blob/main/process_elements_testing.js#L4C29-L7 and then testing it?

I am alien to this repo, but with the reading I did it seems that we need to alter that logic (?)

Also, where would we define version > 1.92.0 of posthog-js ?

[andrewm4894]

@Ancairon i think all the processelements* scripts would need to be updated. The thing is that this repo is really based around test driven development. So i think steps would need to be:

1. Update to latest js lib with new structure.
2. Update the tests in here to reflect the new structure.
3. Then edit the code to get the tests passing.

@davemurphysf is it just that $elements is getting renamed to $elements_chain or does elements_chain also have a different data structure?

[andrewm4894]

@Ancairon of course another option could be to just disable the app and see what breaks. Retiring this posthog custom app we had been using in the past could also be something to consider too.

There are more other official apps that could also be used not to give maybe most of the functionality we need.

Or worse case you can just recreate any logic in the downstream bigquery etl if we really need it and would be ok with losing the custom property from the posthog UI.

[davemurphysf]

@andrewm4894 $elements_chain is a string representation of the $elements JSON. We were already doing this processing in our data pipeline, and then we realized that there was no reason to not just do this on the client (here's exactly what we're now doing on the client: https://github.com/PostHog/posthog-js/blob/feca861ef31576d2db32a76c883ba1c3a0da2553/src/autocapture-utils.ts#L366).

So if you go into the Event Explorer for any Posthog team, you'll see both of these values on any $autocapture events. Here's a example values for the same event (I can't fit the entire $elements value in one screenshot):