Maximum call stack size exceeded when working with Turbo

[michael-yin]

trafficstars

I found posthog JS lib can not work with hotwired/turbo, which is a very popular frontend lib in Rails community.

If I click some links to do page navigation, then I will get the "Maximum call stack size exceeded"

And I think there might be some conflict between posthog-js and Turbo

[gsumo]

I am having the same issue with HTMX

[hevans90]

This is a pretty prevalent issue with our next.js 13/turborepo setup, this happens ALL THE TIME:

[jakeonrails]

I got 350k of these in a day for a very low volume website using Rails 7 + Turbo and Posthog. Might have to discontinue Posthog unless there's a fix!

[glassworks-projects]

seeing this as well.

[evdevdev]

Are there any updates on this? I'm running into the same issue.

[pauldambra]

I don't have a rails site set up to test turbo but found this note in the docs

https://turbo.hotwired.dev/handbook/building#working-with-script-elements

Annotate

Are people with this problem using posthog via the snippet? If so can they try adding data-turbo-eval="false" to the script tag?

[evdevdev]

I don't have a rails site set up to test turbo but found this note in the docs

https://turbo.hotwired.dev/handbook/building#working-with-script-elements

Annotate

Are people with this problem using posthog via the snippet? If so can they try adding data-turbo-eval="false" to the script tag?

@pauldambra - that could potentially work; however, there will be an issue when you explicitly want the script tag to be reevaluated.

For example, when someone goes from a logged out to logged in state and you'd want to add a posthog.identify call.

[pauldambra]

when you explicitly want the script tag to be reevaluated. For example, when someone goes from a logged out to logged in state and you'd want to add a posthog.identify call.

There is for sure some mismatch between turbo and posthog-js here.

Posthog-js should be evaluated once per page load.

So, I think we need to be able to opt-out of turbo's behaviour which is what I was hoping data-turbo-eval="false". ofc if there's a better way to do it you all as users of turbo will likely figure it out better than us.

If you want to hold on to a reference to posthog so you can call identify, reset, capture etc that's fine (and the best way varies by application) but it shouldn't need you to evaluate the script tag more than once per page load

[stuartchaney]

Just installed today and currently getting slammed with these :/

Anyone ever find a workaround by any chance?

[pauldambra]

So, I think we need to be able to opt-out of turbo's behaviour which is what I was hoping data-turbo-eval="false". ofc if there's a better way to do it you all as users of turbo will likely figure it out better than us.

If you want to hold on to a reference to posthog so you can call identify, reset, capture etc that's fine (and the best way varies by application) but it shouldn't need you to evaluate the script tag more than once per page load

Hey @stuartchaney are you able to test this?

[evdevdev]

@stuartchaney The data-turbo-eval="false" has been working well for us.

[pauldambra]

I'll close this since we've found out how to have the turbo and posthog co-exist peacefully here https://github.com/PostHog/posthog-js/issues/666#issuecomment-2026323030

thanks for bearing with us all

[stuartchaney]

@earnold @pauldambra - awesome, thank you both - implementing now.

[oalexdoda]

How can we add data-turbo-eval="false" while using the Next.js / React SDK? Not sure if related but this is happening on Next.js app dir turbopack. Absolutely destroys our Sentry events billing.

[flamincode]

Hey, just added the snippet to our NextJS site, and are seeing this issue. data-turbo-eval="false" has not resolved the error. Anyone have insight into other steps that have worked?