Thanks! D20648 should fix that -- it slipped through in D20558.

@epriestley: Try removing a comment, it throws an exception

D20647 should fix this. It isn't very satisfying as a general resolution.

What are you seeing in particular?

Apparently commits don't support CAN_INTERACT capability?

The renderHTMLFooter() method does a bunch of Javascript stuff and isn't actually related to the page footer, but PHUIRemarkupView and renderObjectRefForAnyMedia() were enough of a hint that think I have a reproduction case locally now -- let me figure out what I actually did and this will likely be fairly easy to fix.

Could this be related to the custom footer markup? The code in question hasn't changed in a long time but I suspect maybe it's related to changes in the remarkup rendering code that's adding metadata where it didn't previously?

I toggled developer mode on for a moment and managed to get a stack trace:

• Raise "editing while locked" errors in the transaction layer.
• Changed controllers to catch errors and display them reasonably.
• Warn users about locked config when editing existing provider:
  
• When trying to save a provider when the config gets locked during an edit, show reasonable error:
  

Gate auto-login and trust emails.

We currently have a problem where some of these settings don't make sense or aren't actually used but can be viewed/edited, and this makes it slightly worse.

I'd like to make the "view" page more useful (/auth/config/view/X/) which will probably solve that (by showing the non-secret configuration parameters before you hit the edit screen). That page is somewhat recent and just hasn't really been built out yet.

I was also looking for a way to still render the form, except with all the fields grayed out, since it isn't terribly user-friendly to make someone unlock the config just to see what it already says. This seems tricky though, since there's no AphrontFormView->getChildren() method I can iterate over to call setDisable(true) on.

I think some variation of this probably remains desirable no matter what, since we want to roadblock users before they start doing edits, not only once they reach the transaction layer -- not for correctness, but just for usability, so they don't fill out a form and then learn that their changes can't be saved.

Maybe implement PhabricatorAuthProviderConfigEditor->validateTransaction()?

I'm going to fast-track this to production since the fatal in PHI1334 is particularly unlucky (repository landing page) and I'm pretty confident the change doesn't make anything worse.

@20after4, any chance there's a stack trace for this in the webserver error logs? I can't immediately figure out how to reproduce this locally.

We don't have any customer use cases for this so I'm not interested in bringing it upstream at this time.

Thanks for the report. Fixed in D20642, which may or may not land today because of the holiday.

But we could also do it later.

You can also follow 20190412.herald.01.rebuild.php to add a migration which queues a worker to queue other workers to rebuild the index now. It's probably reasonable to do for Slowvote since installs are unlikely to have millions upon millions of these. But we could also do it later.

Just thinking out loud:

• Remove debugging code.
• Fix "oui oui".