Thanks for the detailed investigation -- glad we've root-caused this and proposed a solution :)

@dgoldstein, also, for future reference the way you find the list of email commands is to open an object of the type you care about (here, a task), click the circle/lifeboat thing, and then click "email commands."

That worked for now -- hacky, but thanks.

The workaround I provided in the task description ("If you click the "refresh" icon next to the Google provider, you can add a second account.") no longer works after D14319.

@epriestley, do you have a time estimate of how long this would take to fix?

Some people on our install are asking about this task.

I think my preference would be the "Improve the error message and provide a button to close the audit" option. @epriestley, how long would this take? Assuming it's small, I think we'd want to prioritize this.

I suspect they're the same, but I'm not confident. I'm happy with closing this as a duplicate, and then trying to repro after T5030 is fixed.

This just bit us again, via a different repro.

We haven't yet applied a local patch for T9263. None of our patches seem to be relevant here.

Actually, I just saw that you switched from .phui-object-item-bar-color-red to .phui-icon-view.red. It looks like we now have 14 color options; that's probably good enough for us for now.

We have 7 priorities (one more than the default). Our new priority is "Blocker!", which we put in between High and Needs Triage.

Also, barColor does not exist in master, we use icon + color now to convey information instead of just color (and yes, icons are configurable for Maniphest).

I think ordering by commit date would be great!

To give more info: I'm sure the order makes sense for some use case (though I can't quite figure out what it is right now). The use case we have (in this scenario) is:

[deleted]

Worth adding:

Thanks for the pointer. We CC external mailing lists on most objects because we use Google Groups as the source of truth for group membership, and it's impossible to keep everything else synchronized with it. T3980 sounds interesting.

Thanks!

Our install isn't running any custom CSS. One of our engineers published a Chrome extension that re-skins Phabricator, and it looks like @ianm is running that extension. Ian, disabling the extension should help.

By inspecting the network call that that search field makes, I was able to find a URL for the custom search engine use case:
https://secure.phabricator.com/search/?query=foo&search:scope=application&search:application=PhabricatorPhrictionApplication&search:primary=true

Faster method:

• Visit the wiki (eg, on this install it's https://secure.phabricator.com/w/)
• Change the dropdown next to the search bar to "Search Current Application"

• Perform a search using the search bar at the top of the page

Any workarounds you can suggest until this fix is pushed? I just tried to edit a Herald rule on this install (https://secure.phabricator.com/herald/edit/109/) and can't because of this error.

Thanks for the comment! @epriestley, with that in mind, is bin/remove destroy our best option? Will we be able to receive upstream support if this command causes issues?

@devd, I want to make sure I understand this correctly -- the task seems to be about making one specific use case of lint easier (not linting in general) but is vague about what that use case is.

At a glance, in views that don't otherwise indicate priority (eg, workboard with natural sort order), I'd like to be able to visually distinguish between all of our different priorities.

It sounds like the problem you want to solve is that people sometimes land code before tests have finished running, correct?

@epriestley, what do you think of the problems/use cases @aj described?

Sorry, I spoke without actually knowing for sure what bin/remove destroy does. I was guessing based on the warning text ("Destroying objects may cause related objects to stop working, and may leave scattered references to objects which no longer exist.") that it would leave dangling edges.

We think we just ran into this today? But the problem mysteriously resolved itself after 2 hours, so we can't be much help in reproing.

@ryanseu, can you explain the use case and why setting the view policy isn't sufficient?

Just installed XHProf and ran another profile. Services:

Chrome network console shows 654ms for the AJAX call to /differential/comment/inline/edit/####. The Services profile shows:

In that case, this is a dupe of T8588.

Now that I think about it, one possible explanation is if we're executing O(N^2) queries for each workboard column of N open tasks. (The sum of the squares of the number of open tasks in each column is 2924.)

According to DarkConsole's services tab, query takes 12s overall.

That sounds like another great solution option for this problem :)

I just updated T8522 with some more information -- we had database issues that night (possibly related to the later corruption, unsure) and I can't repro it.

I think this was a fluke. I later discovered that, about 15 minutes before I filed this bug, our database host had gone read-only and we needed to reboot it. This caused transient issues for the rest of the night (eg, none of our phdaemons were running for about an hour until someone kicked them).

I would propose that we make this task into: Prefetch/cache 50 users and 50 projects for the typeahead.

Another option: after T5791 is closed, you could temporarily write a global Herald rule to disable emails for the actions you're about to take, then delete the rule when you're done.

I really enjoyed reading this comment thread! :)

Re-running my experiment (typing two characters at a time), AJAX calls are now taking 700-1000 ms.

At rPee8de4a, this is (mostly) no longer timing out -- but the AJAX request is taking anywhere from 7 to 29 seconds to complete.

In addition to the text being wrong (it always says "marked 0 inline comments as not done."), I'm observing that state is not being saved -- I mark a bunch of things as done and submit/save, only to see that many have become un-marked as done.

Yes, it is.

Some more useful data:

• Last week (before we upgraded Phabricator), I needed to create a user for something. I created a user from /people/, used ./bin/auth recover to log in as that user, and then the web UI immediately presented me with a "you must verify your email to use the website" screen.
• Today, I just went through the same steps -- and instead of seeing "you must verify your email," I see the "login failure" page.
• I checked our database to find a full list of all users with isEmailVerified=0. It's a bunch of really old test accounts, and then new accounts created this week. Every other account on our install is email verified.
• I double-checked our settings. auth.reuqire-email-verification displays as "false" in the list of all config settings, but when I click into it, it says "Value (Use Default)" and then further clarifies "By default, verification is optional unless auth.email-domains is nonempty." Our auth.email-domains setting is non-empty, so I think we do require email verification.

auth.require-approval is false
auth.require-email-verification is false

Do any of the details I provided in T8504 (like the mention of the gray circle) help you understand what's going on here?