Posthog Node or Posthog JS for edge runtime

[kyleqian]

I'm running a NextJS app on Cloudflare, which only supports edge runtime. I'm currently using Posthog Node and experiencing some issues with await client.shutdown hanging in prod. Is it recommended I use Posthog JS for edge runtime?

[benjackwhite]

For a server side runtime you definitely want posthog node. The JS SDK is very much so designed around the browser.
In terms of issues you are having that is definitely interesting to know about? Shutdown will loop over and flush data but outside of issues with our ingestion endpoint I can't see why it would hang. Do you have timeframes metrics around when this happened?

[kyleqian]

@benjackwhite I'm calling await client.shutdown() right after client.capture(...). I also have the PostHog client flushAt set to 1 and flushInterval set to 0 (so, immediate flushing supposedly). My expectation is that having shutdown there should be redundant at worst, but not hang. I've had weird issues with not flushing in the past, which is how shutdown ended up there despite the client being also configured for immediate flushing.

This happened many times earlier today, but here are two specific logs I captured (shutdown is called right after each log):

1. Nov 12, 12:50:57.726 PT
2. Nov 12, 12:52:46.179 PT

Other details:

1. Only happens in prod (for which we use Cloudflare)
2. Happens inside a Nextjs Server Action (but only on the second time that server action is called; which is.. very bizarre - maybe a caching issue?)
3. Shutdown seems to be ignoring the shutdownTimeMs param. I put in a manual Promise.race for 3000ms and that at least prevents the indefinite hanging.
4. [email protected]

[benjackwhite]

Thanks for the extra context. I couldn't find anything in our logs around timeouts or ingest issues around those times so its unclear what could have caused it. I know the way the code works it will respect the shutdown time but not perfectly. It just checks after each flush to see if the timeout has been reached. If the http call for the flush timesout in a weird way though then it could for sure just hold way too long.

I'll take a look and see if there is anything that can be made clearer there. I'm still a bit lost however as to why the fetch calls would be hanging given our server logs around those times look very good. It might be better to make the shutdown call respect the timeout, regardless of what is happening in the background. I'll see about making that change

[benjackwhite]

Got a PR here to respect the timeout forcefully PostHog/posthog-js-lite#305

Doesn't answer the question as to why this might be happening though. One step at a time.

[kyleqian]

Got a PR here to respect the timeout forcefully PostHog/posthog-js-lite#305

Doesn't answer the question as to why this might be happening though. One step at a time.

Cool, this affects Posthog node too right? Also, in my case should shutdown be redundant/noop, because the client configs say to flush every event? I don't see how I can truly ensure flushing without having some kind of await, even with the client configs the way they are, which is why I leave it in.

[benjackwhite]

Yeah the linked PR is the repo that powers a few JS based libs including posthog-node.

The reason the shutdown is needed is the flushing happens in the background. Shutdown is designed to gather up all in progress flushes, await them and flush in a loop if necessary. So it is only a no-op if the previous background flush occurred reliably.

If you are using shutdown its actually recommended not to reduce the flush configs as the shutdown takes care of it nicer.

[kyleqian]

Got it, thanks!