If you'd like us to look at it, please file a separate bug report with reproduction instructions, following the guide in Contributing Bug Reports.

Awesome! Sorry for the churn here -- I think we have a brighter future on the other side, but have to break a few eggs to get there.

This does not describe a bug in Phabricator. See Support Resources for help understanding available support resourecs.

Okay, I saw php7.1-mysql and just wanted to make sure you were aware.

Although I earlier (in T6630#85282) felt like it was reasonable to consider separating Audit and Diffusion, there are now more existing or planned integration points and I think this approach is significantly less reasonable than the "merge them" approach. It also doesn't seem to be causing any problems on real installs.

This doesn't reproduce for me and we don't support third-party code, but it's entangled with T11114 and can stick around until I get rid of the old table.

Particularly, this does not reproduce against the upstream. All patches can be re-run in order with ./bin/storage upgrade --no-quickstart --namespace ..., and we do this somewhat regularly. This process runs cleanly:

We've formally frozen this method after D17158. The UI now encourages project.edit.

Intentional; see T12026 and T12027.

Presumably resolved by D17171?

Thanks for the report. This should be resolved at HEAD of master. Let us know if you run into anything else.

This was collateral damage from D17164.

After D17169, the clusterize command, the error message, and the documentation should be more helpful in anticipating and resolving this situation. (The documentation may take ~24 hours to actually regenerate.)

we can probably ditch that outright?

You should be able to return a list of appropriately configured PhabricatorEditEngineProfileMenuItem objects as builtins, rather than defining a new class for each application -- since "Create Task" is just "EditEngine link to the create task form", etc.

I marked D17168 as fixing this -- it just makes the replacement migration more robust, but I think that's the best we can do from the upstream. No idea how null ended up there in the first place, but I'd guess we have no way to figure it out and our lives would be no richer for knowing.

You should be able to safely update these rows to have '' instead of NULL, then continue:

Ah, sorry, I overlooked that you're using edges.

Oh -- try subclassing DifferentialCommitMessageCustomField instead of DifferentialCommitMessageField directly?

The other side of the Conduit call still issues an hg (or git, or whatever) command in most cases, but sending everything through Conduit means a different host (one which actually does have a working copy) can give us the answer if necessary.

They shouldn't interact -- T10753 is mostly about clustering. When Diffusion and the daemons need to ask questions about a Mercurial repository, they're supposed to issue a Conduit call so Phabricator can get an answer by asking another host if it needs to. In a few cases, they currently just issue an hg command, which only works if the repository is present (and up to date) on local disk.

I'm just going to merge this into T9548 since I think bundle2 support will fix it?

I believe this was resolved by the introduction of the "query overheating" mechanism, described in T11773.

I'm going to merge this into T5815, which is a more general discussion of action queues.

I can't reproduce this; we can't move forward without reproduction steps.

I'm just going to merge this into T10448, this task doesn't have anything not already covered there.

• DiffusionCommitQuery has had the "good" version for a while.
• We're nuking Releeph at some point.