fix: PostHog events not sending — init in provider, not instrumentation-client#32
Merged
Merged
Conversation
…vents now send) Root cause of the 0-events-in-PostHog problem: posthog.init() lived in instrumentation-client.ts, which Next builds as a separate entry. That gave it a different posthog-js module instance than the app bundle, so init ran (the remote config.js loaded — making it look wired) while every capture() in PostHogPageView / track() hit a second, uninitialized instance and silently sent nothing. Web analytics stayed at 0 despite real traffic. Fix mirrors the working kyma setup: a single shared client in src/lib/posthog.ts (initPostHog + exported posthog) initialized inside a 'use client' PostHogProvider mounted in the root layout. init and all captures now share one instance. $pageview is captured manually on initial load + every route change (usePathname only, to keep the ~800 static pages static). track() routes its dual-write through the same module. Verified locally: with init in the provider, the browser actually POSTs events — /_ph/e/, /_ph/i/v0/e/ (pageview), and /_ph/s/ (recording) all return 200. (Confirmed by temporarily disabling the bot-UA filter so the headless test browser wasn't filtered; that flag was reverted before commit.) Removes instrumentation-client.ts and components/posthog-pageview.tsx. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the real fix for "0 events in PostHog despite traffic".
Root cause:
posthog.init()was ininstrumentation-client.ts— a separate Next build entry. It got a different posthog-js instance than the app bundle, so init ran (remoteconfig.jsloaded → looked wired) but everycapture()in the app hit a second, uninitialized instance and silently sent nothing. Hence config loads but no$pageviewand Web analytics = 0.Fix (mirrors the working kyma setup):
src/lib/posthog.ts— single shared client (initPostHog+ exportedposthog).src/components/posthog-provider.tsx('use client') — inits inside the React tree + captures$pageviewon initial load and every route change.layout.tsxwraps the app in<PostHogProvider>;track()routes through the same module.instrumentation-client.ts+posthog-pageview.tsx.Verified locally: browser now POSTs events —
/_ph/e/,/_ph/i/v0/e/(pageview),/_ph/s/(recording) all 200. (Temporarily disabled the bot-UA filter to test from headless; reverted before commit.) Build green (878/878). Will mirror to SSOT.🤖 Generated with Claude Code