Toolbar loads incorrectly when using multiple posthog instances

[benjackwhite]

From #1163 @panrafal

---

@benjackwhite Sure, there are basically two issues here:

I have two instances of Posthog reporting to the same project. One is using all bells and whistles and is capturing only once user gives their consent. It reports heatmaps, autocapture, recordings, etc. The second instance is for manually capturing anonymous actions - with a shared distinct_id. They're separate, so that non-anonymous tracking doesn't leach out by accident to the anonymous actions.
When the two toolbars show up, one of them displays a big warning that it doesn't work because decide is disabled. It does display data though, but only because it's being capture by the second instance. As toolbar stores it's preferences on a single localStorage key, touching any of the toolbars will overwrite the other one. They're simply not very compatible with multiple instances.
As for solutions...
For 1) - it's very specific to my use-case. This PR, while fixing nr 2, solves my main issue. I could also refactor it to just accept an option, like disable_toolbar.
For 2) - now as I'm thinking of it, the warning probably is too excessive and it lead me to believe it won't work without decide. Debugging or creating actions do make a lot of sense even without it.

So I'd propose to add the disable_toolbar option, or add the projectId to the toolbar storage key, ensuring at the same time, that there's only one toolbar active per projectId. The second is probably more sound, but the first I believe would be much efficient to implement.

---

Sounds like we need to fix the clashing localstorage keys or something, rather than adding more config options. I want to be sure that will solve it so just need a few more details on how to reproduce.

• Screenshot of the error message
• How the two instances are configured

[panrafal]

Oh, the warning is not about decide, but heatmaps being disabled 🤦 My brain did some kind of a shortcut...

Nevertheless, I have two toolbars on the same page, both showing exactly the same data, and both always showing one on top of each other. Despite the warning, heatmap data obviously is displayed.

As for the instance config, the full-blown uses:

    posthog.init(getPosthogToken(), {
      persistence: "localStorage+cookie",
      persistence_name: POSTHOG_PERSISTENCE_UNPREFIXED_COOKIE,
      respect_dnt: false,
      secure_cookie: true,
      capture_pageview: false,
      capture_pageleave: true,
      enable_heatmaps: true,
      enable_recording_console_log: true,

      opt_in_site_apps: true,
      request_batching: true,

      // We want to initialize the lib to keep the feature flags working
      opt_out_capturing_by_default: !consents.identify,
      opt_out_persistence_by_default: false,
})

And the anonymous is using this (they both use the same token, but have different distinctID):

    posthog.init(
      getPosthogToken(),
      {
        persistence: "memory",
        persistence_name: "ph_anon",
        opt_out_capturing_cookie_prefix: "ph_anon",
        opt_out_capturing_persistence_type: "localStorage",

        disable_persistence: true,
        disable_scroll_properties: true,
        disable_session_recording: true,
        disable_surveys: true,
        advanced_disable_decide: true,
        advanced_disable_feature_flags: true,
        advanced_disable_toolbar_metrics: true,
        ip: false,
        autocapture: false,
        capture_pageview: false,
        capture_pageleave: false,
        respect_dnt: false,
        save_referrer: false,

        bootstrap: {
          distinctID: `anon-all`,
        },
})

You can see it in action on https://www.mycapitally.com/

[benjackwhite]

Thanks so much for the extra context.

I get what you mean now by the error message. In which case, yeah I think disabling it for the other instance makes sense.

I have two separate but related ideas:

1. When loading the toolbar bail out if one instance is already loaded. I think this would work as long as the "standard" instance is initialised first
2. Add a method to posthog-js like captureStateless which would allow you to pass the distinctId and capture an event separate from the rest of the SDKs config. This would avoid the need for duplicate SDKs potentially. Would that sound like something useful for your use case?

// uses the standard distinct_id
posthog.capture("my-event"); 

// uses the given distinctId and doesn't affect any of the stored state
posthog.captureStatless({ distinctId: "shared-id", event: "my-event", properties: {}}) 

[panrafal]

The idea to just bail-out makes sense to me. I don't see much sense in having two toolbars on one page. Btw, if there is more than one project in use, the toolbar could have project selector - obviously if this ever becomes an issue.

As for the second, that would actually be great, but it would need to meet a few requirements:

• the event should be sent out regardless if the instance is capturing or not. Currently as I understand, the queue is stopped if you opt out. Such stateless capture should overcome this - could actually be sent without queue, batching or retries (or be controlled)
• I should be able to include some standard stateful metadata in the payload - things like browser, current url and so on. The function could accept options what to include, or better yet, posthog could expose a method to get the currently set properties, environment metadata (browser, beta flags etc.), url and referrer. So in general, that you have more granular control over what is being sent out. I'm currently sanitizing properties to make them anonymous, but not removing everything.

In general, I think having a standardized way to be able to do anonymous captures would be great. As currently you either have to be fully anonymous, or fully tracking. I'm moving from Mixpanel where I have this setup and it's working great so far, but couldn't find anyone else doing the same 😂