https://www.growthbook.io/ logo
Join Slack
Powered by
Hi, my team is using the Ruby SDK and running into...
# ask-questions
b
Hi, my team is using the Ruby SDK and running into an issue with the tracking callback. The “Include experiment/variation names?” option is set to yes in our production and staging SDK connections, but the names are only being sent in staging. I don’t see any relevant config differences between the environments in the feature, experiment or SDK. Any troubleshooting tips appreciated. 🙏
m
It looks like a bug where the webhook payload is different from the CDN payload in that the "include experiment/variation names" toggle isn't being respected in the webhook payload. Below is a screenshot of the webhook payload and the CDN payload for the same key in the same environment.
cc @fresh-football-47124 - would you mind taking a look at this issue? I believe it's a bug in the GB platform. Thanks.
cc @brief-honey-45610 any help here would be appreciated, thanks.
b
Hi Jon, I’ll ask one of the engineers who works on the Ruby SDK to take a look
m
Thanks @brief-honey-45610. It doesn't look like a Ruby SDK issue though. This has more to do with the webhook payload on the Growthbook side.
b
Ok gotcha, I saw Jenna was using the Ruby SDK and made an assumption. In that case I’ll ask the engineers who work on the webhooks features
m
Thanks!
h
Hey there! We might not be purging the SDK payload cache correctly when you toggle "include experiment/variation names". I'll have a closer look and see if I can patch this for our next release. Meanwhile, assuming that this is the issue, you can probably force your SDK Payload cache to invalidate by toggling a random feature flag (off -> on -> off) within that same project & environment to force the cache to clear.
m
Hi @happy-autumn-40938, thanks for looking into this. I tried the random feature flag toggling approach as you suggested and it didn't work, I'm still only seeing keys in the payload.
h
are you using cloud or self hosted?
m
cloud
h
@wonderful-garage-54008 and/or @brave-dress-50667 (assuming you are also on Cloud)... If you have a moment, could you DM me the URL to the SDK payload / feature definition that is showing the incorrect format? I can have a look and see if I can figure out what's going wrong
m
@happy-autumn-40938 Sorry, I'm not sure what you're asking for, can you clarify? Are you looking for a Growthbook URL to our webhook settings? Or a URL to see our webhook payload? Thanks.
h
b
@happy-autumn-40938 The endpoint correctly returns the name, but Jon's screenshot above shows the webhook payload missing the name. Let me know if that's helpful or you're looking for something else, thanks.
h
Update: We're are comparing the legacy webhook payload with the CDN'ed SDK endpoint, and the key difference here is showing/hiding the names. Legacy webhooks are in maintenance mode so they do not receive new features (such as name filtering). If you can explain your use case, perhaps we can find another way to achieve the same thing without using the legacy webhooks.
b
Thanks Bryce, that's what I suspected. We need to get real time updates as features are modified. The new (beta) webhooks could be a possibility but seem to be missing key config options, like environment and project.
h
what sort of service needs realtime updates? We do have SSE / streaming support if your service is able to install a supported SDK (javascript, react, java, go currently)
if that doesn't work, you could possibly also tap into our proxy webhook which is per SDK connection
b
Thanks, good call- this is for our Rails application and it seemed like the legacy webhook was the only viable option for getting these updates.
h
if your goal is keeping a repository of cached values that your app & services share, then using our GrowthBook Proxy might be a good choice. If your Rails app simply needs updates for whatever other reason, then the next best thing might just be hijacking the webhook intended for our Proxy (at least until we can add a better solution).
b
Cool thanks. Is that compatible with the ruby sdk?
h
The proxy webhook or the proxy itself? For the webhook, it's just a POST of the SDK Payload to 
{yourHost}/proxy/features
b
The proxy readme mentions exclusive support for react/js so that's what I was referencing. I see what your saying about the webhook though. Let me look into this a bit more and get back with any questions - thanks for the help here!
h
The proxy is not exclusive to those SDKs; rather streaming update support is limited for React/JS (and also now Java and Golang, sorry!). The proxy is just caching middleware as infrastructure (between your app and GB API), with streaming being one of the many add-on services for that middleware.
👌 1
b
Right, that makes sense.
68 Views
Open in Slack
PreviousNext
Powered by