Staring a bit more at the data I just posted, it occurs to me that it seems kind of sluggish for an UPDATE like those -- one row, indexed by what I assume is the PRIMARY KEY -- to take 1-4ms or so, as these are. There's probably a DB (or network-to-DB?) performance issue there that we'd benefit broadly from addressing.

We're still seeing this issue pretty severely, on our shiny upgraded 2017 Week 17 version on our shiny new Phabricator host. So I took a look just now with DarkConsole.

This issue is in fact actually fixed 🎊 ! Most recently, moving to a new host with a newer PHP (and everything else, running Ubuntu 16.04 rather than 12.04) made a big difference; we've also made a lot of improvements to our Phabricator setup over the past year or so, some of which likely helped too.

Just in my personal experience, I think it was sometime in the last 6 months that I realized Phabricator has a concept of "application search" and "global search", and that a lot of the searches I'd been doing were the latter and that's why they were so limited in functionality. I'd been using Phabricator for years and always had the sense that search didn't work very well, and that there were different forms I might get for it with different sets of fields, and it was unpredictable which one I'd get; but it wasn't until I became responsible for actually running Phabricator and started paying much closer attention to its concepts that I twigged to that pattern as the explanation for which searches got which form.

I'm also slightly confused because, as someone just reminded me, the usual behavior of arc patch is to apply the patch to the appropriate base commit for the revision, not to try to do it on the current HEAD. In this context, that seems like it'd mean applying it directly to the arcpatch-A branch, rather than try to cherry-pick that commit up on top of where the user ran arc patch from.

Also T6482 seems like it's fixed. I've been quite appreciating how Arcanist is increasingly aware of dependencies between revisions.

Having a generated-paths variable in .arcconfig with a similar semantics to the differential.generated-paths server configuration -- something like D11537 a couple of years ago was intended to do -- would be really useful!

We weren't running quite HEAD then, but we were running a version that was our patches on top of something about a week old -- see the end of the description of T11743, which was the first report in that chain. Our version today is a couple of months old, so I see why that'd feel different.

This helped! Thanks for another fast fix.

Thanks also for the tip about SIGHUP to get a backtrace! Had not known that, and it looks extremely useful.

Deployed this on our install, and it worked -- resolved all symptoms of T11743. Thanks again for the swift fix!

Sweet -- thanks for the fast fix! I'll try applying it locally to clear out the affected tasks we have, and to make sure any new ones don't get me paged tonight. :-)

Thank you! Not every day someone invites me to cause a crash on their production server. :-D

Just made P2011, and I think that's a repro -- the "Show Details" link hangs.

Nope -- pstree shows no subprocesses when the worker is stuck.

Meaning here on secure.phabricator.com? Sure -- no guarantee it'll work, but I have some guesses I can throw at it.