See PHI1361. An install sometimes copies data from "production" to "development". When they do, the phabricator.base-uri for the install changes from production.phabricator.example.com to development.phabricator.example.com.

However, the repository_uriindex table has literal scalar values for hosted URIs, and doesn't recognize this change:

mysql> select * from repository_uriindex;
+-----+--------------------------------+-------------------------------------------+
| id  | repositoryPHID                 | repositoryURI                             |
+-----+--------------------------------+-------------------------------------------+
| 793 | PHID-REPO-2psrynlauicce7d3q7g2 | github.com/phacility/phabricator          |
| 794 | PHID-REPO-2psrynlauicce7d3q7g2 | local.phacility.com/diffusion/1           |
| 795 | PHID-REPO-2psrynlauicce7d3q7g2 | local.phacility.com/source/phabricator    |
| 796 | PHID-REPO-2psrynlauicce7d3q7g2 | local.phacility.com/diffusion/P           |
...

We end up with a development.* install that still has production.* URIs in the index.

This can be fixed by running:

phabricator/ $ ./bin/search index --type PhabricatorRepository --force

However, it would be better to fix this automatically so the index does not need to be rebuilt after a phabricator.base-uri change.

I think the most likely fix is to make PhabricatorRepositoryURINormalizer->getNormalizedDomain() normalize the base URI as some kind of magic token like <phabricator.base-uri>, then add a repository reindex migration. This would mean the index looks like this (literally):

- local.phacility.com/diffusion/1
+ <phabricator.base-uri>/diffusion/1

This is likely fine; this index is already very aggressively normalized by URINormalizer.

This runs into some amount of additional mess with phabricator.allowed-uris, but I believe that option is very rare and I'm not sure it should even exist anymore.