Thanks again! :slightly_smiling_face:

All done, sorry for the wait

Thanks for all your help here — please let me know when the gate’s ID type has been changed!

Yeah that all seem reasonable - I think we were hesitant at first to allow people to change the ID type but seems like a reasonable advanced feature. Perhaps we will expose it behind the “Resalt” option, as both of them change the rollout in similar ways like you said above

My hunch is that this is going to become more frequent in the future — so we’ll either be asking you to migrate more as one-offs, would want a self-serve tool for updating ID type, or (potentially) ask for a way to change the default ID type for new gates — but that feels sufficiently far in the future that I don’t think it’s worth solving for now.

Just that one for now, please

Correct, the “Everyone” condition is a % of the unit type of the gate. Any others youd like me to migrate for now or just the create_autotag_workflows?

Also, is this best practice for setting up a partial rollout — selecting “everyone” as the criteria?

Thanks. Can you please update https://console.statsig.com/1RGPypreBznu0OcFtjp2pX/gates/create_autotag_workflows on your end to use the `communityId` ID type?

I think we dont expose that in the UI, but as you transition over I’d be happy to change the ID type on the backend for you if you give us a list of gates. But correct, you would need to register the customID type in the console and start passing it in code

The other question I’d ask is: can we modify the ID type of an existing feature gate (resalting is allowed, and modifying the ID type feels similarly destructive/no more dangerous), or do we have to create a new feature gate?

Sorry, one more point: • This is not possible using custom fields. We also need to modify our codebase to pass this as a custom ID (which is different from custom fields in the API). I see that `StatsigUser` has type: ```export type StatsigUser = { userID?: string; custom?: Record< string, string | number | boolean | Array<string> | undefined >; customIDs?: Record<string, string>; ... };``` so custom fields and custom IDs are different, despite being similarly named.

Thanks for the pointer. We have not yet set up a custom ID type for this team ID custom field. To double-check my understanding, this means: • We will _not_ get stability by team ID if we roll out on this custom field using our existing gate, since the existing gate uses the user ID type. • If we set up custom ID types and create a new feature gate that uses this ID type, then this new gate _will_ get stability by team ID. Is that correct?

https://docs.statsig.com/guides/experiment-on-custom-id-types|This doc talks about running experiments on custom ID types, at the time we wrote it we only supported it on experiments, but we’ve since added the same concept to gates as well

We’ll add these details to the appropriate places on docs. Thanks for pointing this out!

For your 2nd question, yes - when you increase the rollout, we just grab additional buckets from those that are failing, so users who were previously passing will continue to pass

Yes - it’s pretty easy to do partial rollout on IDs other than user ID. You just need to select the corresponding ID type when you create the gate, then whenever there is a partial rollout, it will use that ID to decide which unit should pass/fail. E.g. if a gate has “company ID” as the ID type, and then the rule is “Everyone pass 50%“, then 50% of all company IDs will pass

I've read the docs on stability and resalting for partial rollouts of feature gates. We're b2b so we roll out most of our features to entire teams at once, rather than to individual users. We accomplish this by sending the team ID as a custom field; historically most of our rules have been 0% of teams, 100% of teams, or a specific allowlist of teams. Could we do a partial rollout to (say) 10% of team IDs? This seems to be possible in the UI, but the docs don't cover this case so I'm not sure how it would work in practice. In particular, the docs say "Gate evaluations are stable for a given gate, percentage rollout, and user ID." Are evaluations also stable for a given gate, percentage rollout, and custom field value? And then another question not covered anywhere I can find in the docs, relevant to both user ID rollout and custom field rollout: if you increase a rollout from (say) 10% to 15%, does that necessarily include the original 10% plus a new 5%, or is this 15% group independent of the old 10% group? I'd assume the original group is included but I don't see this explicitly aggressed in the docs.

I think that would probably solve our use case (as we don't actually *need* exact specification, it was just how we were achieving the stratified sampling). Would definitely be interested in info on this as it gets built.

oh yeah, we do have plan to have stratified sampling (some time next year). It won’t necessarily allow you to specify which exact ID should be in which group, but it will try to balance based on some attributes

Hmm okay, the SDK still shouldn’t throw in that case so we will look into that, but I think this is a better integration anyway

Ok yes that works now :slightly_smiling_face: Thanks again for helping me get to the bottom of this. If I return early when userNid is null then it works

Hmm interesting. So when the user object changes, we do have to re-trigger the network request to update the values. Are you able to only render the provider once you’ve fetched those values?

Maybe even some way for us to include customer segments as attributes, and the tell Statsig to randomize (but evenly distribute by these attributes) would be helpful.

Thanks! Yeah, I think some simpler workflow for doing this would be helpful. While the workaround of checking the ids in code might work, it also eliminates a lot of the benefits of using a platform like Statsig if we need to implement our own flag checking on top.

Without doing that though not sure what you recommend for grabbing the userId

Seems the issue has to do with setting any state here

So the issue is with calling useAuthContext() from within the Statsig provider i'm creating -- the AuthProvider has all the info on the current user, so without it I can properly initialize the userNid / etc. If I remove the useAuthContext() and instead try grabbing the id directly from async storage, it also gives the same error saying call and wait for initialization to finish. If I remove all this code and just send in 'test' for nid it works fine ```import type { FC, ReactNode } from 'react'; import React, { useEffect, useState, memo } from 'react'; import AsyncStorage from '@react-native-async-storage/async-storage'; import env from 'react-native-config'; import DeviceInfo from 'react-native-device-info'; import { StatsigProvider } from 'statsig-react-native'; const MyStatsigProvider: FC<{ children: ReactNode; }> = ({ children }) => { // const { userNid, currentUser, initialize } = useAuthContext(); const [userNid, setUserNid] = useState<number | null>(null); useEffect(() => { void (async () => { const _userNid = (await AsyncStorage.getItem('nid')) ?? null; setUserNid(_userNid != null ? parseInt(_userNid) : null); })(); }, []); return ( <StatsigProvider sdkKey={env.STATSIG_API_KEY} user={{ userID: userNid ?? undefined, appVersion: DeviceInfo.getBuildNumber().toString(), custom: { // isInternal: currentUser?.isInternal ?? undefined, // username: currentUser?.username ?? undefined, }, }} waitForInitialization={false} > {children} </StatsigProvider> ); }; export default MyStatsigProvider;```

Not that I can think of. Could it be something weird with naming it the same thing as the exported StatsigProvider from the sdk?

Would any part of the internal implementation of the Provider cause this to happen? It's a bit annoying now because I need to access another context from the same file to get the user info :sweat_smile:

I’m not sure I have an explanation for that, but Im glad its working for you!

Huh, strange

I moved it into App.tsx and works fine

Not sure why that would affect things :man-shrugging:

Ok I found it -- seems like the issue is with how I was declaring the StatsigProvider in a separate file

Nope that didn't do it

To simplify things a bit and try to narrow in on the issue, maybe just simplify the user object you are setting on the provider? Like just hard code it to {userID: “test”}

Hmm that's weird -- ok will try upgrading to that version and circle back

(side note, we did publish `4.8.0` as a production version with the other fix we discussed, so you dont have to use the beta version any more

hmm Im still unable to reproduce the issue, with `waitForInitialization` false, I just get `isLoading: true, value: false` for `useGate` calls in my component hierarchy