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

In T11506#193270, @epriestley wrote:

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.

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.

(Self-reminder of the downstream report: https://phabricator.wikimedia.org/T624#2606686 .)

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

I'm starting this now.

Is worth to mention that PHP 7.1 RC1 is available. Does it resolve our problems with comparability?

No problem and you're welcome.

We don't take Design/UX suggestions as feature requests, unfortunately. Thanks for the suggestion, we'll keep it in mind.

I tried to rephrase slightly to clarify the root cause rather than looking for a solution.

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.

:) It's not a very important bug, but isn't it still a bug that the button shows up?

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

Got it.

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

I was expecting to see exactly the view in your screenshot -- changed files expanded inline, and moved files described as such.

What are you expecting to see there instead, exactly?

I wonder why I had a different behavior:

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

Okay. If I diff this:

I suspect that diff.renames has the same behavior from recent versions, just that it is enabled by default.

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

Wow, that's strange. Is it possible that you have a different setting for diff.renames?

I can't reproduce that:

Yes, I'm not claiming that git can somehow not show actual changes, just that it doesn't show file renames. This is what I was doing:

I can't reproduce that either:

Thanks anyways!

We can't move forward then, sorry.

I was thinking of what you see when you then do git add, git commit, and git diff HEAD..HEAD^. I might be using the wrong terminology perhaps

No sorry, I don't have logging set up on that server.

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'm honestly not sure. I followed the normal upgrading instructions as always:

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).

You can today, just extend PhabricatorGuideModule and drop it in src/extensions. It should just show up.

Maybe it might be a good idea to allow people to create own Guides? Could be helpful for recuring setup stuff for newusers for example, like we got it at our instance.

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

Can you walk me through how this is a bug?

All notifications currently show up in the same place, so I think the consistency here is better than something new. I'd be more apt to try new treatments in general vs. moving it. We'll probably need to revisit "something on the page changes" UI if we ever build realtime workboards.

We'll take this into consideration and keep an eye open for other feedback,

For people who suffer from this: Note that D16483 might have actually made things a little worse, by searching the DB for old messages (Not loading them though); I tested with 1M messages on an SSD drive, and I didn't see any changes, but YMMV.

The shell is probably eating away the ". Try surrounding the whole argument with ' to stop it.

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.

Hi Avivey, many thanks for the feedback.

I'm not sure how this wasn't reported earlier, I guess the module cache prevented everyone from encountering it?

FWIW, PHP 7.1.0 RC1 was released today, and it includes the async signal change. The following amended script from T11270#184087 seems to work:

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%+.

Just some quick googling revealed this issue with a prior version of APCu.

I turned it back on and ran additional load tests but Apache was able to handle everything. To be honest, I was surprised how well the site held up with APCu turned off. The numbers are about the same.

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