fix: do not allow default integrations multiple times

[marandaneto]

💡 Motivation and Context

follow up #217 and #216 (comment)
if multiple instances are created using the with method, we might send data wrongly or too much.

💚 How did you test it?

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

[marandaneto]

ups, copy-pasta error

[ioannisj]

I’m not convinced if this is the right approach tbh.

Integrations are effectively handled in a first-come first-served basis, so instance creation order matters here, which could be problematic. If instance creation happens in a non-deterministic order as well, then this will lead to unpredictable results down the line.

Consider this scenario:

• HostApp integrates with PostHogSDK.
• HostApp also integrates with SomeOtherSDK.
• SomeOtherSDK, in turn, integrates with PostHogSDK.
• Both HostApp and SomeOtherSDK enable all integrations in config (session replay, autocapture, etc.).

In this setup, whichever SDK calls .setup() or .with() first takes precedence. This could introduce inconsistent behavior if the call order is not guaranteed—sometimes the HostApp gets all the active integrations, while other times SomeOtherSDK does.

Broadly speaking, I feel this ties back to how we handle multiple PostHog SDK instances.

Maybe a more robust solution would be to introduce a mechanism in the instance creation process that will ensure a single PostHogSDK instance per API key, each with its own configuration and set of active integrations:

• Calling .with(apiKey: "project_one_api_key") multiple times should always return the same PostHogSDK instance, ensuring that integrations are installed only once and that events, session replays, and autocapture are delivered to the "project_one_api_key" project.
• Similarly, calling .with(apiKey: "project_two_api_key") should create a separate instance for that project with its own set of integrations, sending data specifically to the "project_two_api_key" project.

In the scenario above, HostAp and SomeOtherSDK will get a seprate PostHogSDK instance, with all integrations active for each.

wdyt?

[marandaneto]

I’m not convinced if this is the right approach tbh.

Integrations are effectively handled in a first-come first-served basis, so instance creation order matters here, which could be problematic. If instance creation happens in a non-deterministic order as well, then this will lead to unpredictable results down the line.

Consider this scenario:

• HostApp integrates with PostHogSDK.
• HostApp also integrates with SomeOtherSDK.
• SomeOtherSDK, in turn, integrates with PostHogSDK.
• Both HostApp and SomeOtherSDK enable all integrations in config (session replay, autocapture, etc.).

In this setup, whichever SDK calls .setup() or .with() first takes precedence. This could introduce inconsistent behavior if the call order is not guaranteed—sometimes the HostApp gets all the active integrations, while other times SomeOtherSDK does.

Broadly speaking, I feel this ties back to how we handle multiple PostHog SDK instances.

Maybe a more robust solution would be to introduce a mechanism in the instance creation process that will ensure a single PostHogSDK instance per API key, each with its own configuration and set of active integrations:

• Calling .with(apiKey: "project_one_api_key") multiple times should always return the same PostHogSDK instance, ensuring that integrations are installed only once and that events, session replays, and autocapture are delivered to the "project_one_api_key" project.
• Similarly, calling .with(apiKey: "project_two_api_key") should create a separate instance for that project with its own set of integrations, sending data specifically to the "project_two_api_key" project.

In the scenario above, HostAp and SomeOtherSDK will get a seprate PostHogSDK instance, with all integrations active for each.

wdyt?

discussed this offline.

[marandaneto]

@ioannisj dda9648 (#219)

[marandaneto]

@ioannisj @PostHog/team-replay can I has a review?

[pauldambra]

low context 👍