Hey team, it looks like the behavior of webhooks h...
# announcements
Hey team, it looks like the behavior of webhooks has changed. Is there a way to make webhooks fire whenever feature definition changes, as the documentation specifies?
Hi Rufei, let me take a look
We've tried creating, modifying, and deleting features on our local instance of growthbook but nothing seems to really trigger a webhook POST. It looks like the code responsible for firing them is here: https://github.com/growthbook/growthbook/blob/38414c34dba529b20899c2b7885817f85bd63f15/packages/back-end/src/controllers/features.ts#L472
Unless there is somewhere else governing this behavior, it appears the only condition upon which they are fired is when the "project" of a feature is changed
Before features were introduced, an equivalent webhook seemed to be fired whenever experiment or override definitions changed.
ya, for experiments the webhooks fire for any change - I'll make a PR for this
👍 1
Are you sure you're publishing the feature changes?
fairly certain, i'm clicking through the draft mode to publish the changes
(the webhook url is bogus, but i would expect at least a 400 error)
I'll test it out a bit more
cool, I'll blast my testing db and see if that changes things
what version are you on?
I pulled latest docker image yesterday,
Build: e8714f7 (2022-06-01)
okay Rufei, I debugged what's happening
looks like the webhook is queuing up correctly
but because the URL is incorrect, it's failing silently
so we need to improve the error handling on our end
if you have access to mongo, and look in the 'agendaJobs' collection, you should see webhooks named 'fireWebhook' and you'll see the 'failReason'
Copy code
request to <http://whatever/> failed, reason: connect ECONNREFUSED whatever:80
oh interesting, I see the entries in
so the first request needs to be served to a valid endpoint successfully once before the error is stored alongside the webhook entry at all?
I'll set up a listener on ngrok to check it out on my end, but if it's as you say this is good news
The code is looking for 'lastSuccess' for that webhook - but since the webhook is failing that's never set
I'll add some code to grab the last error and display it for future
Okay, just committed a change to better show the errors when a webhook fails
That seems to have been it, confirmed that the webhook fires to a ngrok listener whenever features are modified. Thanks for the help Graham!