Large HogQL table insights (by number of rows) with datetime fields cause excessive DOM size and page crashes

[isAdrisal]

Bug Description

Bug description

In the last ~3 weeks (or so!), the PostHog website has been responding very slowly compared to previously. Navigating between screens using the left tab bar can take >30 seconds at times, as well as issues with insights loading (which I've seen reported in other Issues).

Today, the website is crashing entirely and displaying Chrome's "Aw snap!" Error code: 5 screen.

Separately, queries that used to take <5 seconds to run now take >40 seconds in some cases.

How to reproduce

1. Load https://us.posthog.com/project/XXXXX
2. Wait for it to load
3. Try clicking any other screen and wait for it to load very slowly

Additional context

Debug info

Session: https://us.posthog.com/project/sTMFPsFhdP1Ssg/replay/018f5b0a-d3ac-7cc6-b56a-74e71d86962c?t=523 
Admin: http://go/adminOrgUS/018a1aa0-fba1-0000-7c63-3525ad2656c8 (Project: 34169)
Sentry: http://go/sentryUS/34169

[isAdrisal]

Also to add, the page unresponsive modal has been appearing frequently:

Is it possible that there's a memory leak occurring somewhere? This is taken from Chrome's memory panel in dev tools. The page crashes before I can finish recording a snapshot.

[pauldambra]

Hey 👋

I use Chrome all day with Posthog with no slowdowns... so there's something going on here that we can maybe fix at least :)

if you try in an incognito window or with no extensions running do you see any difference

[isAdrisal]

Yep, same thing happens in incognito with no extensions.

This is also not limited to just my laptop — it's affecting our whole team, so it's at minimum something related to our project.

[isAdrisal]

@pauldambra I've narrowed down the issue to our main dashboard — https://us.posthog.com/project/34169/dashboard/93091

There seems to be a bug that's causing a huge number of data-floating-ui-portal elements to be created which is then breaking the page and causing it to crash.

[pauldambra]

Oh fascinating! And I guess explains why we don't see it there must be a variable amount created or a condition we're not hitting

Amazing investigation skills!

[isAdrisal]

@pauldambra I've narrowed this down even further to the specific issue.

We have a number of large HogQL table insights that return >1000 rows in the full query. Those insights also have one or more datetime fields (eg. timestamp, person.created_at, etc) — which Posthog renders with a nice formatted relative time.

Hovering over those formatted times (eg. 1 day ago) shows a popup with the full datetime information in the project timezone, UTC time, etc.

Each one of those formatted dates creates its own data-floating-ui-portal element which is used for the hover popover, and presumably, is backed by its own React memory objects.

Altogether, this is what's causing our main dashboard to crash as we've recently been onboarding many more users and thus seeing larger results returned by those queries.

It would be great if we could have a fix here, which I'd imagine could include (with my own biased opinions):

• Ideal: Make rendering the popovers more efficient as only one can be hovered at a time. Eg. reuse the same data-floating-ui-portal popover for the entire insight rather than for each datetime cell value. That way we can still scroll through the full query and theoretically not be penalised for each additional row of data as we are now.

• Quick (?) fix: Limit the number of rows shown in the dashboard without impacting the full query when clicking through to the insight. This feels like a compromise and will simply delay the issue until the query itself grows large enough that we'll run into the same issue on the insight page.

• Not ideal alternative: Introduce pagination on the HogQL query results table (ideally not this one either as it makes it harder to scan through a large set of results).