Hm, I see. Thanks for the explanation.

I hadn't tried to test that! You appear to be correct.

Here is our multimeter data:

We saw a bunch of lines like:

Updated mailing lists in Herald action 1466.

Thanks, can no longer repro after upgrading.

Thanks for tracking down the root cause! It'd be great if the fix were landed today so that we could pull in this fix when also pulling in the fix for T8455.

Our stack trace is very similar -- it starts in Conduit, then calls PhabricatorApplicationTransactionEditor::buildSubscribeTransaction and the rest of the stack trace is the same as what @asteinlein posted.

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

I've most often noticed this when "associating project" on a Maniphest task. I'd sometimes have to wait several seconds for the typeahead to appear.

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

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.

Sorry for the delay, we only just upgraded.

Just to chime in, one use case I've seen that often accidentally repros this bug is:

(Well, slight clarification: I should say probably fixed. I guess we'll know once we update, but any future discussion can take place in T7664.)

This has been fixed as part of T7664. We need to update our code to pull in the fix.

Thanks @chad! I just tested your changes on a local install, and I think the content looks much better now.

(I am not a CSS expert, and I fully recognize the possibility that I'm seeing headers in a different font family than you are because my browser/OS has different fonts installed. But what I am seeing is what I described above.)

As far as I can tell from looking at the CSS console, here is the status quo:

• Remarkup headers (==) get styled as <h2>s. We currently display these in Source Sans Pro, normal (400) weight.
• Remarkup subheaders (--) get styled as <h3>s. We currently display these in Source Sans Pro, bold (700) weight.

Thanks @chad for the fast fix! The spacing and color look much better now.

Got it. Thanks for that explanation.

Current Changelog page Evan mentioned:

In case it helps: I set debug.time-limit to 25s and got this stacktrace.

Ideally these large files would be collections of smaller files, and we have made progress towards this, but I suspect it will be a while before all such cases are completely fixed.

Sorry, I'll make sure to describe problems in the future!

We are at rPd8ab5f59, which is ahead of rP8efdc4aa.

Maybe it's naive of me to expect that our Monday update actually updated to the then-latest HEAD. Let me check and get back to you.

I'm seeing a similar (possibly the same?) bug. We just updated our install this week, so I presume that we have D12116.

Although this is a rare edge case that we're unlikely to run into again, the fact that it ate up an hour of my life makes me think that spending ~5 hours to fix is worth it just in case we ever do run into this.

If you disable passwords as an authentication provider for your test install, does the email content change?

This is the email he received:

I like the idea of !subscribe, !projects, etc. What's the status of that?

I stand corrected. (Is this new in the past couple months, and I just never noticed?)

I'm going to speak for myself here, and not for any of the other subscribers on this thread.

I talked to @btrahan today who mentioned that part of the problem (with lint, at least -- not sure about unit tests) is that linters are allowed to modify code, and you don't want that happening at land time because those changes will be unreviewed.

Thanks @epriestley!

Any of those options sound fine. I don't have a good sense of which solution would be the most elegant to build and maintain.

Our workflow is that we have a tool that automatically files tasks via email. We actually used to route these using Herald (not quite the approach described in T5039 and this task, but something similar -- we'd put key words in the body of the email, and write a Herald rule that assigned projects based on body text) but this quickly became unscalable. Relatively few people in our organization have permissions to create global Herald rules, so that became a bottleneck. It was also difficult to check if a tag from our email system had a corresponding Herald rule or whether we had forgotten to create one. I'd imagine we would face similar problems with routing via multiple email addresses + Herald.

The originally reported bug was (roughly) "associating projects via mentions when editing a task is annoying." I agree that this is annoying when editing a task -- but I view it as a crucial feature when creating a new task.

Thanks! Good point, I should have tried reproing on HEAD. (I did search for commits that sounded like they would have fixed this, but didn't find any.)

This looks awesome! What's its status? From @nipunn's last comment, it looks like everything is working except for the backfill?

Sounds good. I've been reading through the diffs and tasks you've CCed me on, and I like the direction you're headed in. I'll probably stay silent and lurk in the shadows for now unless I have further questions.

epriestley's suggestion

Wait, how does your suggestion work? This line means that $rows would be a mix of array objects and phutil_tag objects, so (I think that) you can't pass that into array_mergev.

Oh look at this helpful documentation that some kind soul (who must spend all his time frustrated with PHP) wrote! https://secure.phabricator.com/book/phabflavor/article/php_pitfalls/

Hm, I guess it's actually slightly more complicated than that. The Conduit endpoint needs another field for the commit. In our case, we're not guaranteed to be hitting this endpoint in increasing commit order. (I don't know Phabricator well enough to know if this is easy -- if it's not, you can ignore me.) A nice-to-have would be for the Conduit endpoint to ignore the request and not update the coverage database if it already has coverage data for a more recent commit.