Ben White

Looks like https://github.com/mohankishore/python_dynamodb_lock/pull/285 actually is a nice solution to this exact issue. I get the feeling this project isn't being maintained... @mohankishore any thoughts on how you might want support...

Closing due to the age of this issue. The recorder changes frequently and without specific context per-issue, keeping these old issues around doesnt make sense

I'm thinking of this more abstractly from React as a simple rate limiter on the underlying `capture` code. Went for the React example because I figured that is an actual...

This is a bit stuck in limbo atm due to the inability to filter out these internal events from usage reports... Wondering about changing the logic instead on pipeline filter...

Can't say for sure. Quick glance at the code shows [this as the type correctly](https://github.com/PostHog/posthog-js/blob/master/react/src/components/PostHogFeature.tsx#L7C38-L7C38) but it could be something else going on?

For what it's worth, testing locally for us and removing the [flushSync call](https://github.com/ueberdosis/tiptap/blob/develop/packages/react/src/EditorContent.tsx#L78) all-together of course stopped the error. Interestingly though through testing a bunch of our custom Nodes and...

# Team Infra ## Hang over items from previous sprint 1. 🟢 Get app onto Canary deploys now that we are on contour @danielxnj 1. 🟢 Test out capture-rs traffic...

The bulk of session recordings are stored in S3 (assuming you are running a relatively up-to-date version of posthog) and you can set whatever lifecycle policies you like on those...

@tiina303 I get a lot of failing tests due to connections being closed and I don't know why. Any idea what might be happening?

Overall it looks fine code-wise so I'm wondering if you could add `posthog.debug()` and check it is outputting something that looks sensible.