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.

Removing an email does not properly disassociate identities. This unambiguously should.

When you set an identity to "Unassigned", we also set the effective PHID to "Unassigned". This isn't strictly incorrect, but probably makes everything more complicated than it needs to be.

• When you set an identity to "Unassigned", we also set the effective PHID to "Unassigned". This isn't strictly incorrect, but probably makes everything more complicated than it needs to be.

The internal construction with LIKE '%...' is also not great:

Looking up identities by email address is improperly case-sensitive, because the query is a LIKE query against a binary column.

Here's a list of bugs I expect exist, although I haven't made it far as reproducing them yet:

We currently have bin/repository rebuild-identities, which takes a list of repository identifiers or --all. This has a lot of history in T12164 and we currently queue an "activity" for it during migrations in 20180809.repo_identities.activity.php.

I've marked D20905 as resolving this. This isn't really "resolved" completely, but T13454 has a better description of what the problems are and why they're difficult. Our behavior is, at least, substantially better than it was before.

I have a fancier version of this in the works.

On Ubuntu 14, the messages are a little less helpful: