I think there's another one of these in DivinerAtomController->composeTasks(). The other getDocblockMetaValue() calls anywhere in the codebase are also suspicious.

Oh man -- I didn't notice that the random test account I was logged in as in Chrome (named wwwuuu) was an administrator. I have a repro.

Part of this is likely a change to the semantics of setTimeout(). Current uses are:

@epriestley : Alright then, Thanks.

Sounds good. Let me know how I can help

Alright, thanks. I'll look at this in more detail.

You can manually edit conf/local/local.json instead of using bin/config set.

@epriestley : Ouch! - Alternatively since all of you are already on it. What git commit can i revert to quickly fix this? (Note it was a clean clone i am trying to re-setup)

Nope, that doesn't work either..

Sniped!

Does this work?

The 24-hour data in multimeter shows a drop from about 1.1M requests per day to about 41,000, so that's a slightly-better-than-95% reduction in request volume. The worst sample we caught in the last 24 hours for api.almanac.service.search was 228ms, and the median was closer to 70ms.

This is somewhat involved to untangle because the old logic was actually wrong and had a small chance of executing a page incorrectly.

Opened T11593: *.search Conduit API methods with invalid constraints silently ignore the constraints for this.

Ill go true Contributing Feature Requests and submit it properly.
This is a must feature, even gmail add it today with blue dot! (maybe its partial release)

Ah, okay, that's actually consistent with what I'm seeing -- I think I repro'd the web version. You do sometimes need to restart the web thing to get this flow to work fully (we run some special, more-helpful checks during setup, which is only run after restart), but I believe it doesn't matter in this case since the setup checks are a little buggy.

maybe I need to restart?

It does work from CLI, not from web.

Specifically, we only take feature requests as problems, that is, that you have an issue you're not able to solve currently in Phabricator. This idea is nice, but problematic when combined with all the possible applications we have (in particular our chat client Conpherence). If we do anything with the favicon, it'd likely be for direct mentions.

let me try again since I've gotten sleep. 8)

@chad, I'm having trouble reproducing the patch from P2007 not working. Here's what I did:

This doesn't appear to be a valid feature request. See Contributing Feature Requests.

@epriestley You (and your team) are freaking epic. I owe you a beer (or several). If you're ever near Basingstoke, UK drop me a line!

I don't think we should actually trim() the address -- if you have bad data in LDAP, you should fix it.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable.

Even though I think there's a good technical argument that our behavior is reasonable, the lifetime support cost of changing the application logic to be more similar to what browsers do is almost probably lower than the lifetime support cost of documenting this explicit port behavior, since there will be 100 more people who try the same thing in the future and maybe 5 of them will read the docs if we're lucky.

Adjusting the redirect to use `phabricator.pt.local:80' also fixes the issue, though I have removed it as I don't think anyone here still tries to use an IP...

Confirmed, removing that redirect at the top of my apache config. also resolves the problem without changing the upstream.

This is probably the issue:

I had to look that up its been so long since I fiddled with the server hosting.

Prior to that change, we did not send ports in Host: headers in requests.

Spot on! reverting that change on my arcanist client resolved any issues completely.

If you revert rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be in libphutil, does that fix it?

I can replicate the cURL error from a configured repository, its the same trace as that of the arc which command above:

[2016-09-05 10:06:49] EXCEPTION: (HTTPFutureCURLResponseStatus) [cURL/47] (http://phabricator.pt.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS at [<phutil>/src/future/http/HTTPSFuture.php:408]
arcanist(head=stable, ref.master=9e82ef979e81, ref.stable=10e519475290), phutil(head=stable, ref.master=c8b76485ef84, ref.stable=f748cdbc8d08)
  #0 HTTPSFuture::isReady() called at [<phutil>/src/future/Future.php:37]
  #1 Future::resolve(NULL) called at [<phutil>/src/future/FutureProxy.php:34]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistWorkflow.php:332]
  #4 ArcanistWorkflow::authenticateConduit() called at [<arcanist>/scripts/arcanist.php:356]

Interesting:

echo '{}' | arc --trace call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
 ARGV  '/home/sam/bin/phabricator-tools/arcanist/bin/../scripts/arcanist.php' '--trace' 'call-conduit' '--conduit-uri' 'http://phabricator.local/' '--conduit-token' 'cli-37au4odrzomsk54zbnolivacknw3' 'user.whoami'
 LOAD  Loaded "phutil" from "/home/sam/bin/phabricator-tools/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/sam/bin/phabricator-tools/arcanist/src".
Config: Reading user configuration file "/home/sam/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/sam/Coding/UMC/Src/.arcconfig".
Working Copy: Path "/home/sam/Coding/UMC/Src" is part of `git` working copy "/home/sam/Coding/UMC/Src".
Working Copy: Project root is at "/home/sam/Coding/UMC/Src".
Config: Did not find local configuration at "/home/sam/Coding/UMC/Src/.git/arc/config".
>>> [0] <conduit> user.whoami() <bytes = 117>
>>> [1] <http> http://phabricator.local/api/user.whoami
<<< [1] <http> 195,683 us
<<< [0] <conduit> 195,955 us

What do you get if you run the same command with --trace flag ?

Further testing, the standard curl request seems to be fine:

curl http://phabricator.local/api/user.whoami \
>     -d api.token=cli-37au4odrzomsk54zbnolivacknw3
{"result":{"phid":"PHID-USER-omtmnetw55dqsgt576g7","userName":"Sam","realName":"Sam","image":"http:\/\/phabricator.local\/file\/data\/g57z5iku5s2x4rpi7k6r\/PHID-FILE-xhdrpuvh5lbu7tmkfso5\/profile","uri":"http:\/\/phabricator.local\/p\/Sam\/","roles":["admin","verified","approved","activated"],"primaryEmail":"Sam@blahblah.com"},"error_code":null,"error_info":null}

It also works from the web-conduit application in phabricator http://phabricator.local/api/user.whoami, but it fails from arc:

echo '{}' | arc call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
Exception
[cURL/47] (http://phabricator.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS
(Run with `--trace` for a full exception trace.)

Weird.

How about subpages? It would be really useful to be able to print out / export an entire hierarchy with one click.

Maybe it is ok for the import from LDAP module to trim leading and ending spaces.

To correct my previous post.
The real cause of the error is Email addresses should be in the form 'user@domain.com'.

New Info.

Hmm, yeah I wonder if it's anything we can detect on our end. Doesn't sound very common though.

I just tried again. It seems that I miss the latter part of the error message.

Do these fail for you during single person invites as well or only during LDAP?

These are valid email addresses in Phabricator. I don't have any other ideas why you're running to an error.

For example, I want to import
readonly_user readonly_user@company.com readonly_user readonly_user

I am not able to reproduce any issue with these email address formats. Do you have any suggestions for how I can do things differently?

What is the exact error message you received?

After upgrading and several weeks of the icons not disappearing,

I poked a bit at this, but I think PhamePost is a special case, since it doesn't have a direct edit policy, it's edit policy is derived from PhameBlog and it's not clear to me how comment transactions get around edit policy in general reading through the code.

J772

hunter2

thx

This appears to be deployed and stable. I'm going to leave this open for 24 hours so I can get a reading out of Multimeter tomorrow, but looks like everything worked as intended.

Please follow the instructions in Contributing Bug Reports if you'd like to report a bug. Thanks!

FYI, there is a report about a regression from multiple users at WMFs-Phabricator: https://phabricator.wikimedia.org/T144338

(rSERVICES1fcb5cdb758211f6389729956d7c77f90edc2243)

I caught an issue with D16464 and lazy/partial parsing of the "Host:" header on the repo tier, deploying a fix for that now.

I've been fiddling with host destroy while letting things settle. Here's load on admin001 over the last week: