I think T11934 and an explicit !claim Txxx action (which would mean "reassign + ref"; maybe with a !claim-and-fix Txxx to mean "reassign + fixes" or some kind of !claim+fix X syntax which expands to !claim <args>; !fix <args>) is a possible way forward on this, but I don't want to make "ref" automatically mean "claim".

Because of the high degree of complexity there's basically zero chance we'll ever build this without active customer interest, and we have none today. Closing this until interest arises.

We don't have any use cases for this today so I don't plan to pursue it. It's conceptually reasonable, but complex, and there's no customer interest.

T11934 is a possible way forward on this (and other niche things) without adding a lot of Javascript and UI complexity, by supporting it through !fixes.

One possible approach for this is:

I'm going to roll this forward into T13057.

We shipped "Mentions" and "Duplicates" some time ago.

See T13056 for followup.

One attack is that you can override the content of email and then send invite or welcome mail that says whatever you want, whether the victim has a Phabricator account (welcome) or not (invite).

After T13049 this is relatively within reach, but we haven't seen other requests for it so I don't currently plan to pursue it.

This is relevant now that work related to T13049 has added CSV support.

More or less obsoleted by work in T13049.

That's as far as I plan to take this for now. I think the additional features described above (filter, reorder, reformat, and broader field and application support) are all reasonable if use cases arise, but am not currently aware of use cases. We can return to that stuff when use cases arise.

I just let that run for a while but it finished at some point:

I'm going to roll this forward into T12677 since SES managed to one-up this by a healthy margin in T12237.

(They got back to me and we're scheduling a call.)

Mailgun has yet to respond to me after about three weeks, so I send them a followup.

The compaction completed overnight. I'm optimizing the tables now.

Pool is full again, repo is upgrading, edges are compacting on the instance shard.

web004 is deploying now.

web004 died abruptly so I'm going to fix that and deploy these changes at the same time.

Resolved by D18959 + D18960. See also T13049.

Even on our fairly normal data, the effect was a little bit more dramatic than I'd expected:

D18962 uses this to implement "Export Data" for large result sets.

I'm going to optimize + probe secure001 now and see if any of the tables above shrunk. I'm expecting a very modest effect combined with zero user visible changes in the UI despite throwing away a bunch of data.

Took like 3-ish minutes and did this:

I double checked that our backups are working.

Editing some edges on the new code as a sanity check before I compact things.

(Pushing this to secure, stuff might be funky for a minute while I gently massage the database.)

It looks like PHPExcel was formally deprecated on December 24, 2017 but I'm not planning to switch to its successor, PhpSpreadsheet, until we run into some specific motivator.

See PHI324.

See PHI323.

This hasn't had any stability issues for a while.

transaction.search now returns comments and inlines, including path, line, length, and reply information.

I think everything we know about has been resolved.

This is resolved as far as I'm aware. See also T11767 (improvements to these limits), PHI125 (similar issue with non-UTF8 attachments failing to insert) and T13053 (planning).

I'm rolling this forward into T13053.

If that doesn't work, you might try adding some logging to PhabricatorDaemonEventListener->handleLogEvent() to see if the sequence of events you're receiving matches my expectations or not. It's hard to log out of this context because normal tools (var_dump(), phlog(), throw new Exception(), etc) won't necessarily end up anywhere very helpful, but you can do this to create an ad-hoc logfile:

The daemon log (at /daemon/) shows status icons for running (or recently-known) daemons. This stuff lives in PhabricatorDaemonLogViewController. The status PhabricatorDaemonLog::STATUS_WAIT represents two (slightly-more-than-two) different scenarios: