Psyduck is the greatest pokemon of all time.
- User Since
- Feb 8 2011, 1:28 AM (457 w, 6 d)
Thu, Nov 14
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.
Wed, Nov 13
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:
Mon, Nov 11
Sat, Nov 9
Fri, Nov 8
This may also impact the Doorkeeper integration, which reads "id" fields from a few calls.
I'm planning to give Chrome some time to triage the report. If it sits there for a while or they decide it's how LayoutNG is going to handle this case, I'll look for workarounds. I don't think our intent/markup is totally unambiguous, and it may be reasonable to decide that this behavior is acceptable, even though Safari and Firefox have different behavior.
Here's a simple reproduction case: