Webhook Subscriptions and Restart

[SBarnes]

Does a call to the restart route force a reloading of the webhook subscriptions or is that only achieved by restarting the windows service?

What I am trying to get to is how to refresh the subscriptions after a change has been made to the subscriptions via the api and the only way at the moment seems to be restarting the self-hosted service through windows at least that's what some external programmers are claiming.

I have an external programming team that claims they are not refreshing but unless I am not reading something correctly WebhooksSubscriptionsPATCHRequest and WebhooksSubscriptionsPOSTRequest both update the in memory list as well as the database.

[Mike.Sheen]

Does a call to the restart route force a reloading of the webhook subscriptions or is that only achieved by restarting the windows service?

A call to the restart route won't do anything for self-hosted, only on IIS.

If you configure the services recovery properties to "Restart the Service", then a call to /servicestop will effectively be a restart - it will stop the service and Windows will apply the recovery policy and restart it. You can read more here.

What I am trying to get to is how to refresh the subscriptions after a change has been made to the subscriptions via the api and the only way at the moment seems to be restarting the self-hosted service through windows at least that's what some external programmers are claiming.

I have an external programming team that claims they are not refreshing but unless I am not reading something correctly WebhooksSubscriptionsPATCHRequest and WebhooksSubscriptionsPOSTRequest both update the in memory list as well as the database.

Yes, we do update the in-memory list as well as the table. If you have steps to repro an issue, just log a helpdesk ticket and we'll look into it!

[SBarnes]

Thanks Mike,

I don't think its an issue, I believe the issue is at their end and it is refreshing these guys wanted to claim the hook weren't firing and when I looked in messages they were returning a 500, they also wanted to claim they were getting sent the hook four times so I lowered the retry to 1 and they still got 4 copies only to discover the issue is at their end again, this is definitely doing my head in when having to investigate false issues.

The upside is that at least now I have read pretty much all the webhook code in the plugin.