...or what I had just written up, with an added aspect of different levels of information being revealed between web vs mail:

The fix for https://secure.phabricator.com/T1191 was backported to the Wikimedia Phabricator instance.
This triggered a comment in https://phabricator.wikimedia.org/T1191 which displays for me (being an admin in that instance):

Restricted Application added a commit: Restricted Commit.

in the web interface. The email notification for that ticket however stated:

"Diffusion added a commit: rPHUTIL0135e57181a9: Assume utf8mb4 support."

In T6516#83228, @aklapper wrote:

This triggered a comment in https://phabricator.wikimedia.org/T1191 which displays for me (being an admin in that instance):

Restricted Application added a commit: Restricted Commit.

You can ignore this, not relevant to the bug reported here. Currently in Wikimedia Phabriator, Diffusion is only visible to the members of https://phabricator.wikimedia.org/tag/diffusion/ . @aklapper, join that project and you will see the commit.

@aklapper, T6367 discusses the email thing in more detail.

Fix for this is probably some kind of "ignore references in this repository" flag. Prior to adding object mentions you could effectively do this by disabling autoclose, I think, but I believe mentions now punch through autoclose.

We require a full URI for "Differential Revision: ..." to avoid this problem there, but that's not practical in the general case.

Does it also mean that each clone allocates a new PHID for each commit (Because "edges")?

Each copy of a commit in a tracked repository has a unique PHID, yes. This is intentional -- it would be weird/confusing if commenting on rXabcdef1234 mirrored to rYabcdef1234 just because the "X" and "Y" repositories were copied from one another at some point in history. The two commits might also have totally different view/edit policies, etc.

ooh, I was thinking "high availability" clone....

Today Wikimedia Phabricator has been hit badly when we started importing the Phabricator repository (having forgotten about this problem). We stopped the import as soon as we saw our mailboxes flooded with notifications of commits and tasks marked as resolved.

This happened just an hour ago. We are tracking the repairs at https://phabricator.wikimedia.org/T91488

Some related discussion in T6887.

I think the root issue is that repositories created via the Conduit API (e.g., with the script in T6887) are not correctly flagged as "importing" at initial creation. Repositories created via the web UI do get flagged. Most users use the web UI to create repositories, and I always used the web UI in testing this, which is why I missed the issue.

When a repository has the "importing" flag, we mostly ignore all the commit content until we catch up to HEAD and process everything in the repository.

Had the repository been flagged correctly by the API endpoint, most of this damage (in particular, all the status changes) would have been averted. As we made new commits in the usptream their side effects would leak out, but that would have been caught quickly and autoclose disabled in the repository, affecting maybe a handful of tasks (maybe a few dozen if you, say, merged from the upstream after a few weeks).

Object mentions might still have fired. There's an argument that this behavior is correct in some cases, although we should probably disable them if they aren't already disabled. I'll look into this.

Those two patches should generally prevent problems here. With those applied, the behavior would have been:

• Nothing happens during initial import (i.e., we do no publishing of any kind).
• The next time the remote repository updates (on WMF Gerrit), new commits incorrectly publish. If the Gerrit repository is synchronized to the upstream, this would have been approximately one commit. If it's updated manually, it would have been however many commits we made between the update periods. So somewhere between one and "a handful" of tasks would have been undesirably affected.
• Someone notices, goes into the settings, and disables "Publish/Notify" and "Autoclose" for the repository.
• The repository never publishes again.

These patches aren't granular enough to fully support importing external repositories without affecting local objects. In particular, you could not do this:

• Import Phabricator;
• have it not affect local objects;
• but still write Herald rules against it to learn when we push certain stuff.

Specifically, the "affect local objects" and "run Herald rules" parts are not separable, so you have to disable both or neither. I'm not sure if this is actually an interesting use case. If it is, we can separate the "Publish/Notify" option into a "Publish/Notify" option and a "Objects mentioned in this repository are local objects." option.