Toolbar Not Respecting Bootstrap

[iamnafets]

Bug description

The Posthog toolbar doesn't seem to be respecting the boostrap parameters I'm passing over via RSCs. While useFeatureFlag() is reporting "false" for some flags, the toolbar thinks it's true and thus never allows me to override it.

How to reproduce

1. Set up environment to bootstrap flags server-side.
2. Create a discrepancy between the distinctID server-side and client-side (this is not intentional but allows you to reproduce).
3. Notice that the feature flags reported by the toolbar are incorrect vs the flags reported on the server.

Environment

• PostHog Cloud US, project ID: 28776
• PostHog Cloud EU, project ID: [please provide from https://eu.posthog.com/project/settings#project-id]
• PostHog Hobby self-hosted with docker compose, version/commit: [please provide]
• PostHog self-hosted with Kubernetes (deprecated, see "Sunsetting Kubernetes support"), version/commit: [please provide]

Additional context

Thank you for your bug report – we love squashing them!

[benjackwhite]

This might benefit from some more concrete code examples if you have them?

I'm reading as - "im using the bootstrapping concept server side to load feature flags and then client side they are not respected" which makes sense given the toolbar has no concept of what you have overridden server side.

Or am I misunderstanding you're use of "server side" and actually you are bootstrapping the client to set a certain flag to be "true" but when you load the flags in the toolbar it says false?

[iamnafets]

The latter is correct actually, you said that better than I did. The bootstrap has A=false, B=true, C=true. The toolbar shows all 3 as true. Toggling A does not change any flags, but toggling B and C does.

My assumption is that the toolbar is reading its flags from a different location because A is only "overridden" according to the toolbars hypothetical state when set to false.

Hope that makes sense. Let me try to put together a repro.

[iamnafets]

It seems like this is because the toolbar and the page have a different idea of what my distinct ID is. In the network tab I see two API calls, one to decide/ which returns what I understand to be the "real" feature flags and which aligns with what is returned server-side, and one from "api/projects/@current/feature_flags/my_flags" which returns the incorrect flags.

Piecing through the code is seems like the toolbar is using local storage to try to persist tokens, the bug may be there. It's a little unclear that the bootstrap is actually the cause here, but it may be part of it -- the crux seems to be that the toolbar and the on-page posthog are operating off separate distinct ids.

[iamnafets]

Slight update: it looks like the api/projects/@current/feature_flags/my_flags endpoint operates entirely off temporary_token -- which I assume is being generated by the posthog UI to attach a toolbar. I suspect that may be the source of the problem. Any pointers would be appreciated!

[iamnafets]

It looks like the problem may be whether an override is set. I've noticed the color changes to yellow when an override is active.

Maybe even more confusingly, this override actually persists even when the toolbar isn't active which makes debugging an absolutely nightmare. Would be amazing to have a clear indicator as to what's coming from the server, what's overridden, and have the buttons specifically reflect the override.

[iamnafets]

Closing this. I think it's related to more specific issues I opened.

[neilkakkar]

thanks @iamnafets , @liyiy is working on resolving all these toolbar issues this week

[iamnafets]

💪