Herald Webhook is not called but Herald Transcript tells me the opposite


Observed Behavior:
Herald Transcript tells me a Herald Webhook was called but in fact it wasn’t.

Expected Behavior:
Herald Transcript tells me a Herald Webhook was called and it really was.

Phabricator Version:

  • phabricator ffc5c95c2f3dca03a62db25130e89408b707538c (Sat, Feb 10)
  • arcanist 349109426c7f9f86bfd295517e61fdf34cdbcbdc (Mon, Feb 5)
  • phutil f91ef416f11fa22f939f6c2211949669422983f0 (Thu, Feb 8)
  • diff 3.5 at /usr/bin/diff
  • git 2.13.6 at /usr/bin/git
  • hg Not Available
  • pygmentize 2.2.0 at /usr/bin/pygmentize
  • svn Not Available

Reproduction Steps:

  1. Create a Webhook which calls a RequestBin (https://requestb.in/), is enabled and also visible and editable by All Users
  2. Create a Herald rule ( When Global rule triggers for Commit Hook: Commit Content.), which calls the created Webhook (Call webhooks) when a commit is pushed to a hosted Git repository with a specific project (When all of these conditions are met: Repository projects include all of "Your Project")
  3. Push a commit to an untracked branch of a repository with “Your Project” (HTTPS or SSH)
  4. Check the Herald Transcript (HeraldPreCommitContentAdapter) and compare it with the Webhook details (Recent Requests) and the RequestBin
  5. Make also a test request (New Test Request) and it should work


Thanks. https://secure.phabricator.com/D19061 removes the “Call webhook” action from these rule types:

  • Commit Hook: Commit Content
  • Commit Hook: Branches/Tags/Bookmarks
  • Outbound Mail

These events are triggered specially and can not fire webhooks. It was an oversight that the action could be selected for these rules. The UI reflected that the webhook action did put calls in queue, but the queue was just thrown away by the caller.

In the case of “Commit Hook” rules, they fire before objects exist in Phabricator and can not send anything meaningful to webhooks unless the payload for these requests was completely different than for normal requests. For example, they can not send a commit PHID because a commit PHID does not exist yet. They can not send a list of transactions because the object has no transactions yet, and surviving a “Hook” event doesn’t generate any.

You should be able to respond to commits with a “Commit” rule (vs a “Commit Hook: Commit Content” rule) instead. You should receive a payload like this:

  "object": {
    "type": "CMIT",
    "phid": "PHID-CMIT-kgthf4ep2sliorfgm6lp"
  "triggers": [
      "phid": "PHID-HWBH-fy65v6zaiimqj5urr64i"
  "action": {
    "test": false,
    "silent": false,
    "secure": false,
    "epoch": 1518357680
  "transactions": [
      "phid": "PHID-XACT-CMIT-fmy4joxzhmem53o"

Use the object > phid field to call methods like diffusion.commit.search to obtain more information about the commit.

The information this method provides is currently limited. If you have a support pact, you can share your use case with the upstream and we can likely expand the scope of the call in the next release.

Alternatively, you can use the older diffusion.querycommits: this provides more data, but will be removed in favor of diffusion.commit.search in some future version of Phabricator (but that may be a year or more in the future):

Once you have the repository and commit identifier, you can use other diffusion.* methods to obtain additional information about the commit as necessary.


@epriestley Thank you very much for your fast and professional reaction! It’s always a pleasure and more than I can expect!

It was my mistaken assumption (on of the most frequent cause of problems) the trigger would be after the commit is placed. This is especially embarrassing, because I already use Commit Hook: Commit Content to block some kind of pushes in our company. In other words: I should have known this! :see_no_evil:

Anyway we also using the Commit rule already with Harbormaster for building releases on tracked release branches and I was just blindly hoping to build also untracked topic branches.

So I see we have to track all branches in our repositories to get these stage builds until we figure out a better approach; sure one advantage is the possibility to comment on all of them and one drawback will be having some more dead entries in the push logs.

At the end, let me say I’m still excited getting more good features in this stable and clean way like you always develop making Phabricator a great and robust product for our daily work! :slight_smile: