https://www.growthbook.io/ logo
Join Slack
Powered by
This message was deleted.
# ask-questions
w
This message was deleted.
h
Does your experiment have a 
fallbackAttribute
defined anywhere? I'm not seeing it in the definition you pasted above
r
I definitely selected the 
fallbackAttribute
when setting up the experiment. I had a coworker sanity check me while I did it. At one point, 
fallbackAttribute: ''
showed up in the settings, but then it went away shortly after. It seems buggy and random if it shows up and I've never had it show up similar to the 
hashAttribute
where it should be 
fallbackAttribute: 'anonId'
@happy-autumn-40938 after I posted this, my coworker emailed support and August was in the process of setting up a call or something, so I can wait for that instead of hashing it out here if that's preferred.
h
ok. sounds like there could possibly be a regression or a conflict which is clearing your fallback attribute. We'll follow up and get this sorted out
👍 1
p
let me know if you'd rather i start a new thread but i just joined to ask a similar question about sticky bucketing... spent most of yesterday trying to figure it out and failing. but on latest react sdk it seems to me like sticky bucketing is broken... (both local storage and browser cookie) what i'm seeing: • have anonymousId as primary targeting attribute. userId as fallback. • If no userId is present the anonymous id is used correctly and an entry to local storage or cookie is written. • As soon as I log in and the userId attribute is also present, it seems non deterministic which attribute will get used. • I can see cookies stored for both userid and anonymous id (in the browser cookie case) that have different variation values • If I refresh the page a few times I can see track events come through with either variation. I think that since the track events are getting sent at all the configuration is fully loaded and since both cookies are present I should deterministically see whichever cookie was created first. Anyway, I'm curious if there were any findings as part of this thread as it sounds possibly like a similar case. Before I dive further at least or email support.
h
hi @powerful-journalist-78283, can you also confirm whether your experiment definition (in your payload) has a 
fallbackAttribute
defined?
p
yeah. from the devtools:
h
@powerful-journalist-78283 wondering how you are loading the GB SDK. Is it manually imported into a bundle, included via script tag, etc?
p
just pulled in via npm. using the react sdk with next.js
h
can I ask how you're invoking/creating the sticky bucket service? There's a small bug in the React SDK now that doesn't export the service correctly
(although seems it's likely working for you given you have items in LocalStorage)
p
i can see the cookies for sure
Copy code
const gb = useMemo(() => {
    return new GrowthBook({
      apiHost: GB_API_HOST,
      clientKey: GB_CLIENT_KEY,
      trackingCallback: onExperimentView,
      decryptionKey: GB_DECRYPTION_KEY,
      stickyBucketService: new BrowserCookieStickyBucketService({
        jsCookie: Cookies,
      }),
      enableDevMode: true
    });
  }, []);
h
do you import 
BrowserCookieStickyBucketService
from 
@growthbook/growthbook
?
also, is this purely a client component, or SSR as well?
p
yes to first and yes to client component
fwiw i tried to do a ton of debugging and the path i was lead down was that the stickyBucketAssignmentDocs array only ever had one item in it (which correlated to what got sent). example:
it seemed like there should be two entries in there one for primary and fallback
but that's about as far in debugging as i got
h
how many assignment docs do you have in your cookies?
(this is helpful, thank you)
p
new example so here's the gb output:
h
and as far as you can tell, is it random which of these 2 cookie docs actually end up inside your SDK?
p
the non fallback key (anonymous_id) in my case seems to generally be the winner...
h
I wonder if you get the same behavior using LocalStorage. Wondering if its a cookie thing or a general bug
p
i played around with local storage yesterday as well and behavior seemed the same. i can test some more on monday probably
h
can you tell me whether both the hashAttribute and fallbackAttribute are present in the current SDK (user) attributes?
also, when you log in, are you refreshing the page or sdk? or is the prior sdk frozen in place via useMemo? i.e. how does the SDK know the user attributes changed: via refresh or via setAttributes?
tl;dr, The handoff between fallbackAttribute -> hashAttribute when logging in works best when there's an actual page or SDK reload happening. Otherwise the SDK doesn't always pick up the correct StickyBucket docs.
assuming this is the issue you're facing, I've started on a PR to patch this
p
there's the attributes
the user id and anonymous id get set via setAttributes but at different times. so seems like a good lead maybe?
basically we set anonymous id first then do 
setAttributes({...gb.getAttributes(), user_id: 'xxx'})
as the second call
h
yep, that would definitely explain it. the SDK filters SB assignment docs that are potential matches during constructor, so if you're missing an attribute at that point it will never pick it up. This is "by design", but I think we could relax these constraints and pick up new docs when attributes change.
I'm working on a fix for this, but meanwhile you could either destroy and recreate the SDK when you get your new attributes or (harder) force it to flush 
_ctx.stickyBucketIdentifierAttributes
(may be obfuscated and not easy)
@rhythmic-morning-61672 any chance you’re facing a similar issue (delayed setting of user attributes)?
r
Sounds like it. We set our anonymous id right at the beginning synchronously and then when the user logs in, use 
setAttributes
to set the customerNumber.
h
Thanks for confirming. FYI, here is the PR I'm working on to address this and other related concerns. Shouldn't be too much longer before we can ship the fix: https://github.com/growthbook/growthbook/pull/2770
r
Excellent! Would you still recommend recreating the SDK?
h
depends on how urgently you need this fixed I suppose. It will probably be a few days, possibly up to a week before the SDK PR is live
r
Sounds good. Thanks, Bryce!
b
@happy-autumn-40938 does the fix apply to the JS SDK as well?
h
yes: JS, React, and HTML Script tag
❤️ 1
b
@happy-autumn-40938 any idea when this might go live?
h
probably next week. sorry about the delay
👍 1
r
@happy-autumn-40938 thanks for doing that! I see that the changes got merged. How long does a release generally take to go out once it's merged?
h
We have yet to publish the SDKs to NPM, which is when the SDKs officially become available. Meanwhile, we are testing their functionality sandboxed in the GB app (hence the merge to main). Assuming no obvious regressions, we'd likely widely release the SDK changes on Monday
👍 1
r
@happy-autumn-40938 I updated our SDK connection and tried this again, but the fallback attribute is still not affecting the experiment. It still doesn't show in the experiment attributes.
Yeah, here you go. After creating an experiment with a fallback attribute, I've never seen a spot that shows it again. I've always been confused about that.
No network errors that I'm seeing; all 200 responses. Here's what appears to be the experiment call. The fallback attribute appears in the request (first image), but not in the response
I don't see a request to the 
/targeting
endpoint. Here's the call from the screenshots, it's just 
/experiments
256 Views
Open in Slack
PreviousNext
Powered by