This is also not a valid feature request.

Could you reopen and set it as feature request?

This does not describe a bug in Phabricator.

I worked around the update issue by using

git fetch
git reset --hard 6be53bd9160807fb7c829b72b23025d233f7072c

(as suggested on the IRC)

I wish I had saved the logs, but alas.

Do you still happen to have the original error message? That was unexpected, and the migration specifically accounted for the case of email collisions and I recall testing that case locally in detail, so I'm curious what I missed. The expected behavior is that that list wouldn't migrate (and would emit a message), but other lists would:

Not sure the migration works as intended.

Presuming resolved, yell if anyone's still running into issues.

It's only issuing one statement so it will jump from 0% to 100% after adding the key, but it might take a bit if you have a lot of data in the table.

We saw a bunch of lines like:

Updated mailing lists in Herald action 1466.

I believe the error is now fixed at HEAD.

I don't think this really matters if you've decided to fix the issue, but in case you're curious:

If you haven't run into it, T8398 has general context and guidance on this change. I've updated it to include the information here.

Worth adding: most of these were not intentionally created to refer to mailing lists. I think they used to just refer to plain email addresses, but then some migration in the past detected all of them, automatically created mailing lists for them, and automatically changed the Herald rules to refer to the mailing lists. So, I wouldn't be surprised if many installs run into similar issues.

When I run arc diff and attempt to trigger such a Herald rule:

1. arc diff succeeds, and the diff is created
2. the arc diff output includes:

Exception
[HTTP/500] Internal Server Error
{"result":null,"error_code":"ERR-CONDUIT-CORE","error_info":"Edges are not available for objects of type 'MLST'!"}

3. in the diff view (on the website), it looks as if no Herald rules were matched/triggered

See T8398 for any followup issues.

(Note that this stuff isn't in HEAD yet, but will likely land today.)

T8398 has guidance on what to expect when you upgrade.

@epriestly - thx for the heads up. /me fears the next integrate ;)

@klimek, heads up about these changes since I know you're a big mailing list user, too. I'll publish guidance for installs soon (likely in the "Upgrading" section of the weekly Changelog).

@epriestley the latter is particularly important for the FreeBSD case. Already users are getting annoyed at the sheer amount of email that phabricator generates, so having a way to minimize that for particular mailing lists would be great.

I'm going to evaluate giving administrators access to the "Language" and "Email Preferences" panels if they aren't too much of a mess to implement the user/viewer split on, but I think that's all that remains here.

(It's supposed to say "Restricted Revision" instead; there's a bug for that somewhere.)

It's in closed-source (Phacility) code, and makes the "import into phacility.com" tools aware that they shouldn't try to import mailing lists.

D13124 shows up as Unknown Object (Differential Revision). for me. Something meta going on here?

Ah right.

I don't believe this is unexpected. The URI is marked as "Optional".

Its unexpected that these show as links I think? FacebookPOC, for example, is not a link.

What is unexpected here?

Aaaah, okay, that makes sense. Yeah, application limitation. I'll push this box at some point and pick up the fix.

In T7291#96861, @epriestley wrote:

(This isn't Phacility-related, is it? Or did I miss something?)

(This isn't Phacility-related, is it? Or did I miss something?)

PhabricatorMetaMTAMailingList->getPolicy() returns POLICY_USER right now, but should return PhabricatorPolicies::getMostOpenPolicy().