Well, I'll leave this open for confirmation/feedback/etc.

Here's the new AuthProvider code for OAuth2 autologin after D16060:

I'm going to support third-party (as here) and OAuth2 (easy) but we have no use cases for other stuff right now (mostly OAuth1 on Twitter/Jira/Bitbucket, I think).

• Display Preferences gets very angry if Editor Link is empty ("Editor link has an invalid or missing protocol" + all fields are marked "invalid").

All other sections appears to work...

• I get an exception trying to save the global Email Preferences (Argument 1 passed to PhabricatorEmailPreferencesSettingsPanel::getAllTags() must be an instance of PhabricatorUser, null given)

Ah, thanks. We actually have a lot more of those than I realized.

• Customize Menu... link in the homepage 404s.

• Settings → Create Global Defaults as an administrator to set global defaults.
• T11098 for feedback or bugs.

I don't see anything noticeably broken.

• I nuked the corp and clb devices and DNS, and updated the documentation.
• I aligned reserved instances with actual usage after changes.
• I also added secure002 to plb001 (the phurl.io LB).

I think this is live now. I'm going to complete the rest of the deploy and then button up the AWS stuff, but yell if it's horribly broken or whatever.

Here's at least one specific reproduction case which still isn't working well:

Mystery Query: Where is this coming from?

Summarizing caching for my own benefit. See also T10078, T10077.

Observed repositories should now version in a reasonable way.

After D15989, this dialog should properly include information about tree hash and commit hash matches. It could still be more clear, but appears to at least be working as intended now.

Basically, the metadata is sufficient to generate the "Local Commits" table and little else.

The commits are not in Diffusion. Here's a real example of the metadata we store for a commit:

Got it, thanks for taking the time to explain. When you say "metadata" for the commits, do you mean the commits are also in Diffusion (even if invisible)? If so, wouldn't this behavior affect Herald / Harbor Master?

When you run arc diff, you provide (explicitly or implicitly) a commit range. Phabricator stores:

The expected behavior is that when we discover a new commit, we search for any open revision which has an active diff with a commit that has the same commit hash or tree hash as one of the discovered commits. In this case, it appears that this revision did.

Here and in one other report, revisions which are closed by matching a commit or tree hash with a discovered commit are not explaining this in "Explain Why". "Explain Why" is expected to be able to provide details about this: