As a possible attack on this, we could rename phabricator_pastebin to phabricator_paste first and see how awful that is.

Yeah, we migrated a long time ago and also never hit issues.

Haha, thanks for collecting these. I've been meaning to do that...

To tie in some context:

The index should update without needing the daemons, but that code did get touched in connection with T6367, so maybe I fixed something by accident.

Seems OK here, here's the create / detail / search UI:

Thanks!

One thought -- what type of field were you using? I tried reproing it with an "int" field, but maybe the issue is with certain field types or something like that.

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.

Presuming this is resolved, but let us know if that doesn't work for you.

Write "7 days ago" or "-1 day".

I believe the error is now fixed at HEAD.

I believe this is now resolved in HEAD, but let me know if you still see it after upgrading.

FWIW, I do think this UI is poorly designed, and it's reasonable for users to find it confusing: it teaches them how to do something, then takes that away from them.

Why do you need to destroy enough objects for this to matter?

D13205 is a possible fix; if that's the issue, a workaround is to avoid mentioning any users with @mentions in the summary, test plan, or other description fields until it lands.

Do the problematic revisions mention a user with @username in the summary or test plan?

If it reproduces via the web UI on your install, try to hit it on this install by typing stuff in here:

Thanks for the stack trace, in any case -- I'll keep digging; if you can come up with a repro case on this install that might help get things resolved faster.

I'm not immediately able to reproduce this. Does it reproduce for you on this install?

On this task, I got the second email, but the addressee list for the first mail was not computed correctly. This might already be resolved by changes attached to T8455, or might be a general issue related to T6367. I'll look into it.

Use bin/config delete --database phpmailer.smtp-password to delete the database value.

Over time, we've generally increased the barriers faced by new contributors: they were previously lower, and with lower barriers we accepted a number of changes which were net negatives for us in the long run. It is harder to get changes into the upstream today than it was a year ago (and was much harder then than it was in 2011).

(Test...)

Can you fish the server-side stack trace out of the error log on the server? (Usually /var/log/apache2/error_log or similar.)

We aren't interested in bringing this upstream.

See T5462 for discussion about publishing events into remote systems, and why Herald isn't a good choice for doing this.

Can you describe the problem you're facing, not just your desired solution? See:

I think these are the plausible-ish icons that we aren't using anywhere else yet -- this might be missing icons or have icons we can't really use:

I really like how that looks.

Development Log

On the second part, the condition for that query was wrong coming out of D13122: noDisabled changed to isDisabled, but the default value didn't get flipped.

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.

See T8455 for a discussion of some issues. There are fixes there awaiting review, but if you're a larger install and/or use a lot of mailing lists, you might want to wait for the dust to settle there.

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.

Excerpted from a giant novel I wrote but didn't bother publishing:

I can't reproduce this:

The lack of formatting in the text area is a bug, tracked in T8032. The intent is for it to always format. Would that be satisfactory?

Though sometimes I'm typing as fast as I can adding multiple people, in which case I'd still have to wait for the first user before typing the second user?

In Phacility, invite members from the instance administration panel instead of from the instance itself:

Alternatively, we could require usernames to contain a minimum of 16 characters with at least one uppercase letter, one symbol, and three or more of the same letter in a row.

Oh, so you're typing as fast as you can and immediately tabbing out of the field (in less than a second)?