In T13493, PhabricatorExternalAccountIdentifier could also benefit from this null policy behavior.

These callers use accountId:

I think the patch above is a piece of the solution here, but makes behavior worse for some installs: installs with a version of JIRA which returns both key and accountId will have worse behavior under the patch than without it (since it will break all the existing account links immediately). It also doesn't smoothly migrate these installs, even though it's theoretically easy/desirable to do that.

Ah, thanks. Yeah, I think that's reasonable. I'm sure some other things can still be cleaned up -- like I changed the "Subscribers" UI a little bit recently, and it could now handle disabled users more clearly:

When a user logs in to "new" JIRA, we also can't easily tell if they have an existing account link based on the presence of an accountId.

I'm changing the minimum required version to PHP 5.5; see T13492 for 5.5-specific followup.

I have another patch on top of D20998 which brings unit over, but it's currently so broken that it can't diff itself.

I'm also going to collapse as much of experimental into master as I can here, make the minimum required PHP version 5.5 (see T11968), and attempt to collapse wilds.

Probably require PHP 5.4 regardless.

A problem in moving forward here is that we ultimately do very little complex data access in Phabricator, and what complex data access we do perform can often be faked. We likely have more use cases in Arcanist and provisioning code: API calls are slower, workflows are more parallel/interactive, and we can't just fake it all with AJAX.

https://discourse.phabricator-community.org/t/activities-notifications-spam/3286/ is likely a case where curl was not installed on the CLI, but was installed in the web SAPI.

A saved state is likely something like this:

I'd like to leave behind a "Results were GC'd on X/Y/Z" message when we GC these so it's clear what's going on.