This is vaguely involved.

My initial thought was just to add the binary path to the end of the cache key, but the key is also used in PhabricatorAuthSSHKeyEditor to purge the cache, and the cache purge should not really be path-dependent. For example, if you deploy Phabricator from two different paths on two different hosts, updating an SSH key on one should invalidate the cache on both. A simple adjustment to the cache key would mean that only one host saw its cache invalidated. This deployment scheme is exceptionally ridiculous, but within the realm of possibility, even with the scheme described in the task description (for example, half of a cluster may be upgraded to a more recent build, while the other half is still serving an old build).

An alternate approach would be to cache a template document and replace the path outside of the cache layer, but the document is currently built as a string with several layers of escaping.

So we could either:

• purge more aggressively (e.g., all keys with some prefix); or
• cache structured data and build the document from it outside of the cache layer.

Either of these changes require more than a trivial set of edits.

The circumstances required to trigger this issue (moving the directory where Phabricator is stored while it's running) are also rare. The build/deployment strategy described in the task description is also somewhat pointless, because database migrations can not be run backward so it is unsafe to revert to older builds in the general case. I think our behavior is still incorrect and worth fixing eventually.