If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.

See also PHI1594, which wants:

See also PHI1579.

I believe T13462 resolved this.

there is no way to bin/host query against the set of instances using a particular repository shard service

In D20927, I implemented a policy rule like this:

Update Almanac definitions for all instances not on the paired db023 shard.

PHI1566 is resolved narrowly. These cleanup steps still need to happen.

(Updating addresses with bin/host query leaves the service address cache dirty (the "mutable structure cache" via PhabricatorRepository->getAlmanacServiceRefs()) so it should be followed with bin/cache purge --caches general.)

I'll flesh this out more later, but the move away from db123 = repo123 shard pairing, plus bin/host query using mysql makes it difficult to directly query instances using a particular repository service.

Minor issue that should be looked at during service sync arising from improved validation elsewhere:

I'm deploying the new host now. We just crossed a release so I'm going to manually restore it to 72f82abe07 once it comes up (see also T13359). Then, I'll resynchronize instance services for active instances.

Instance termination completed after about 20 minutes and all the volumes detached. Since the original instance can be recycled, I'm going to reattach and restart it, and throw away the replacement host.

Normal volume detachment is just spinning, which isn't exactly surprising. I'm going to give it a few minutes and then force detachment.

To deal with this narrowly, I'm going to:

...

T13463 is approximately the same as this, but now ripe; I'm going to merge this there.

I don't currently plan to pursue this.

In the general case:

I think this doesn't have anything actionable left, see T13444 for some followups. This feature probably isn't 100% perfect quite yet, but I think remaining work is just cleanup.

We materialize some members into the milestone? This causes no real problems, but we shouldn't materialize members into milestones.

We predict the wrong set of members for the milestone when testing policies: we predict "no members", but should predict "exactly the same as the members of the parent project"?

We check the wrong edit policy when testing if you can create a milestone: we check the default application policy, but should check the parent project policy?

Uhhhh, absolutely none of this works because PhabricatorUserEmail does not have a PHID.

Another likely bug is:

Currently, the flow here is that changes queue a daemon task.