The new webhook functionality does not include details and will always require a call by the webhook receiver in order to determine what the event actually is (as far as I can tell).
In most cases, yes.
This makes integration harder because the called application now needs to make a blocking call
(the application might not easily allow that in the place where the webhook is received)
I’d expect most HTTP endpoints should be able to make blocking calls. For instance, I believe almost all modern web applications have some kind of blocking calls to some kind of database.
deal with potential problems like retries, failures, etc.
Phabricator provides some support for retry and failure handling, and the support is unchanged from
You will need to have Conduit client code and handle Conduit errors, but my expectation is that this is not a dramatic increase in complexity most of the time. You can call Conduit by launching a raw
curl subprocess if necessary and the web UI will guide you through how to format the parameters. Obviously, this is still harder than just getting all the data handed to you, but should not usually be a huge increase in complexity.
What would be the best way to go about such a thing?
The absolute easiest way is to use Herald to send events only when something you care about occurred, then ignore what actually happened. If your hook behavior is something like “I want to do something every time someone pushes a commit to
master, but I don’t actually care about the commit”, this might work. I’d discourage this, but I can’t stop anyone.
The easiest recommended way is to write a webhook receiver which can make blocking calls, and do not return HTTP/200 until the event has been completely processed. If you encounter any kind of error, return a non-200 response. Phabricator will then handle retries for you, and continue retrying for 7 days (you can control this by adjusting the GC policy for
If you do this, the only major limit to watch out for is that you must return a 200 response within 10 seconds. My expectation is that almost all webhook receivers can complete processing within 10 seconds almost always. (If an occasional request hits a network hang or whatever, that’s fine: it will just be retried. It only needs to complete within 10 seconds once in the next 7 days.)
If you need more sophisticated control over any part of this, write and endpoint which queues the event somewhere and process it asynchronously.
If you’re comfortable working with the Phabricator platform, you can conceivably write a Phabricator extension which adds an Application, route, Controller, and Worker, then have Phabricator make a Webhook request to itself and process the event in the daemon queue, if you don’t have other processing queues you’re more comfortable working with. If you’re not familiar with PHP or prefer not to work with Phabricator, I think most other languages have tools available for handling this kind of thing.
You can also modify Phabricator to make an internal
transaction.search API call and send this data with the webhook body, like
feed.http-hooks did. Note that doing so will essentially give any user with access to webhooks complete, policy-bypassing read access to everything in Phabricator, which is the major reason that the way this API works has changed.