Using the Sentry Posthog integration on the server with NextJS in Vercel

[osdiab]

I was wondering what is the right way to use the Sentry integration with Posthog in the Vercel environment. Basically:

• Sentry has you initialize in a sentry.server.ts file that Sentry's NextJS bindings seem to call on its own.
• In practice you would need to pass the Posthog client to the posthog sentry integration init function, which is fine
• But where would I call posthog.shutdown() as recommended in the docs?
• And how would it work regarding assigning the user distinct ID during actual requests? Would there be any risk of misattributing Sentry logs if I was setting the ID on the posthog client during requests?
• Or maybe should I use the option in posthog-node to provide the tag like so:

https://posthog.com/docs/libraries/node#example-implementation

  Sentry.captureException(err, {
    tags: {
      [PostHogSentryIntegration.POSTHOG_ID_TAG]: request.user.id,
    },
  })

If I do this, still not sure how to handle the shutdown() function, should I be calling it perhaps by listening for events like SIGINT and calling it then or something?

Some guidance on the proper way to set this up so that server logs can also be tagged with Posthog would make tracking a user's journey across the backend and frontend much smoother, as it's clear how to set it up on the client side. Thanks!

[mason-os]

@osdiab did you end up getting this setup? I'm facing the same questions you had, I'm looking at setting up a Sentry/Posthog/Next/Vercel project with the integration.

[mason-os]

I ended up finding this posthog community discussion (I'm guessing that is you based on the user names!).

The solution at the end of that thread worked for me, specifically adding this block after I initialize posthog:

import * as Sentry from "@sentry/nextjs";
import posthog from "posthog-js";

posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY, {
  api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
});

Sentry.addIntegration(
  new posthog.SentryIntegration(posthog, sentryOrganization, sentryProjectId)
);

This doesn't handle the shutdown issue, but seems to setup the integration in a nice way at least. I'd still be interesting in learning the best practice here!

[pauldambra]

Hey @osdiab

Just checking... shutdown is a method in the posthog node js package... there isn't a shutdown in posthog-js (we just let the browser lifecycle control ours.

Is your question about node or am I misunderstanding

[osdiab]

@pauldambra in NextJS you have both a server-side and a client-side environment because you render your page on the server on one end, and then display it on the client.

I want errors logged by Sentry that occur in the server to be associated with the user that experienced those errors and linked to the Posthog recording URLs.

So there needs to be some kind of set up that happens in the server context (via node, calling functions like shutdown) and another kind of setup that happens in the client context (using the js bindings that perhaps don't call that)

Does that clarify?

[pauldambra]

ok, so... if I understand. you're using SSR (in Next) and want guidance on how you can configure your setup so you can capture errors during both server and client phases of execution - assigning user and replay data to the sentry errors

---

I don't know the answer right now, I guess we'd need to build this and figure it out

---

Or rather I don't know what we can do that's clever here to make life easy. If this was a more traditional app where server and client were separate then we'd advise that you sync the distinct id and session id alongside network calls (in a header normally) so that you can read those on the server.

there you'd be running posthog-node on the server and in your server app you'd read the header and initialise it, or you'd pick up the headers and tag sentry with them.

---

i don't know if we already have (good) content on this... i'll check

[osdiab]

It is possible for us to pull a header or store the posthog id in a cookie to pass it around. But still mechanically I’m not totally sure how we are to be coordinating things between the client and server since I couldn’t find any good documentation about the situation on your website.

That all said, I think a lot of people would be interested in knowing how this ought to be done. NextJS is by far the most used metaframework in the world of React, so I am certain that I am not alone with this problem. The majority of people building a green field react app these days would run into the same problem.

[ivanagas]

This Next.js A/B test tutorial has some details on how to pass an ID between server and client.

You could generate and cache an ID on the server side and then use it wherever (PostHog, Sentry, client, server).

[ivanagas]

Also the PostHog distinct ID will be in a cookie after initial load, so you could use that too.