Ah, I see that it works differently in other shells. The above output was from zsh. In bash, indeed all output is written to the file:

It shows no output because there are no warnings. If you replace phabricator/bin/storage dump with a command that does give various formats of warnings on stderr, you see that it works:

$ sh -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning)
error
error2
$ cat foo.txt
output1
output2

I used the subshell redirection trick as mentioned by @epriestley to hide this warning from our cron output as well:

FWIW, in our case the bug was also triggered by logging in for the first time (for this account) using LDAP.

I just had this problem as well. Turns out I had a typo in preamble.php. A more descriptive error would be nice, but with this task open at least the cause is easy to find :)

Note that it is possible to set a path to the websocket for every server as well. This is handy, for example, when your notification websocket is hosted behind the same URL as Phabricator itself. We have https://phabricator.ourcompany.net/ for Phabricator itself, and https://phabricator.ourcompany.net/ws/ for the notifictions websocket. This corresponds to the following client config:

In T9293#167654, @epriestley wrote:

Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."

In T9293#167652, @epriestley wrote:

$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.

In T9293#167637, @epriestley wrote:

We will not trust X-Forwarded-Proto, X-Forwarded-For, etc., by default because they are not trustworthy in the general case (they are completely client-controlled if you aren't behind a load-balancer).

T8982 is somewhat related, since it is about wrong parsing of notification.client-uri (but it is not related in that it may have the same fix).