Can confirm this is fixed. Yay!

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.

Perfect; thanks!

In the general case:

Sorry if this is a stupid question, but now that this is done, how do I actually map between Phabricator users and VCS user strings, in an existing Diffusion repo?

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.