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

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

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

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.

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.

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

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.

This is probably the issue:

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

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

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!

(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:

Yeah -- I assume they wanted to know as soon as we create a badge, and can't afford to wait more than 50ms!

rCOREddab1d4e shut down the user who was really excited about badges. Looks like they started about 15 hours ago.

Load wasn't dropping as much as I expected, but that seems to be because someone started making 20 requests / second to list badges available on admin in the last 24 hours. Shutting that down now.

I've deployed repo001 and the disk cache appears to be holding. I've checked a bunch of operations and logs without catching anything that looks broken, so I'm going to roll the rest of repo, then db, then web, then look for load effects on admin.

The instance management cache seems OK, new cost is 11 queries in 80ms. The wall-time isn't directly comparable but both numbers being smaller is good.

I've deployed all the auxiliary tiers, admin is up next.

I'm starting this now.

I'm planning to deploy this tomorrow morning. It also looks like the change associated with D16262 (small cache improvement) got a little lost in the switch to bin/host release and never actually deployed, so that's going out too.

• T6064 already covers creating tasks with one click instead of two.
• T10946 covers using EditEngine templates on workboards, I guess. That task is pretty iffy, too. This could probably use a separate, more focused task -- @cspeckmim, if you want to file one describing your use case in a little more detail I can merge T10946 into it if I don't have better ideas for you. (I thought I saw one more of these somewhere while dredging through the backlog to populate Contributor Onboarding but I wasn't immediately able to find it.)
• We don't currently plan to implement a distinct inline quick edit mode like Trello.

See Contributing Feature Requests and Describing Root Problems.

Broadly, this isn't a use case we intend to support specifically. See T5873, T10363, T11330, T11563#192717 for some related discussion.

See Contributing Feature Requests and Describing Root Problems. The context and discussion in T3945 and T9652 may be helpful in formulating a problem description.

No, it isn't a bug.

See Contributing Feature Requests and Describing Root Problems.

So the button already does what you want, but instead of clicking it you filed a bug report?

(Or how our behavior differs materially from the behavior of git diff, except that you have to click one extra time on "Show All Files Inline".)

It's because more than 100 total paths were affected by any kind of edit.

What are you expecting to see there instead, exactly?

If I make a trivial change to one, I get this:

Okay. If I diff this:

The behavior appears to have changed in Git 2.9.0, which was released in mid June of this year:

I can't reproduce that:

I can't reproduce that either:

We can't move forward then, sorry.

In T11578#193135, @venky wrote:

I marked it as a bug because git diff will return something that's pretty small in this scenario.

Does your webserver error log have a long-form version of that error with a stack trace in it?

I can't reproduce this. arc diff is working fire for me and many other users, and 5 different users have created 7 revisions against this install so far today alone (D16482 through D16489).

Can you walk me through how this is a bug?

I believe this should be fixed in HEAD of master. It should promote to stable in about 24 hours.

A bad half-fix for this is here:

I can reproduce this. Fixing it will take a bit of work.

Resolved by D16488.

We'll take this into consideration and keep an eye open for other feedback, but haven't previously seen other feedback in this vein that I can recall and I think most users find this element fairly visible (e.g., T11141 calls a variant of it "an annoying ... prompt", which suggests it's visible enough to be annoying).

We have a parser for comment docblocks, used to generate documentation and extract metadata from source code. This is a docblock:

I'm going to retarget this to make the API more consistent.

We should probably change this API to always return array(), the "sometimes array, sometimes scalar" return value is pretty unintuitive. And any code which fixed this by adding (array) will just work.

I'm going to close this for now since there's no more upstream action available given that the issue either no longer reproduces or disabling APCu appears to fix it and be a reasonable workaround.

Yeah, I think this didn't crop up sooner through a combination of the cache and there being relatively few files with multiple @phutil-external-symbol tags.

We don't really use APCu for very much, so if you are able to isolate it as the issue (or are just suspicious, e.g. based on that launchpad bug looking pretty similar) it's probably OK to turn it off. I'd expect you to lose something like 5% performance with it off, not 50%+.

If you turn APCu back on, does it freeze up again?

I'm not immediately sure about the daemon confusion, although I suspect it's not likely to be a hint at the root issue. Caching for setup issues falls back to some pretty whacky shenanigans with APC/APCu disabled.

That's probably a webhook URI configured in feed.http-hooks (which may no longer be configured).

I don't see anything interesting in Multimeter, it just shows that the host doesn't see much traffic and that we probably need to update some package definitions.

Are you running APC (Config → Cache Status shows APC as the active "Data Cache")?

Also, can you show me what these pages look like?

GET /res/phabricator/86668b8e/rsrc/js/phui/rdar.js HTTP/1.1

This is a bug with how relative/object policies and inherited/indirect policies interact.

I'm going to close this for now since I don't plan to take any further action as the upstream; this appears to be an environmental issue (which we don't offer support for) rather than a scalability limitation (which we do).

I've just dumped this on the pile of arc patch-related bugs. Some of them are likely duplicates, possibly including this one, but I don't expect to dig through that pile until the next major iteration on arc, since at least some of them are likely not addressable without other changes. T11429 has a rough overview of upcoming plans.