I think you should be able to throw any exception to get a reply to the user. Here's what I expect you to get back (from T10709), at least roughly:

This is similar to T9982. Complete that task first, which describes the SQL migration process in more detail.

This is an opportunity to earn valuable contributor points and explore the dark corners of the codebase. Spooky!

Welcome to PHP! This will familiarize you with PHP! PHP is a special language!

Guessing this is the same as T9235.

This will "help" you "become more familiar with Phabricator's codebase".

This will sort of introduce you to modifying arc.

Phabricator can be configured with a "preamble" script, for making certain environmental adjustments to deal with loadbalancers. This is described in Configuring a Preamble Script.

PhabricatorRemarkupFigletBlockInterpreter is a remarkup rule for rendering figlet fonts, invoked like this:

Let's permanently destroy some data! This will introduce you to how to perform schema changes.

Perhaps in a separate change, it would be nice to maybe show the application name under the more modern document types -- for example, show "Diffusion" here:

To reach this dialog, mash some text into the search field in the global menu bar, then hit enter.

In Settings → (Personal Account Settings) → Email Addresses, you can take several actions with email addresses associated with your account, including adding new addresses.

Phabricator ships with a chatbot, roughly documented in Chat Bot Technical Documentation.

I believe this was resolved when D14982 moved us to a first-party client. We now ask for region/endpoint explicitly and I think there's no way to configure the bucketname.amazonaws.com version any more.

This and a few other overly-chatty errors should be quieter after T11480.

I think most of these have been converted now, and the remaining stragglers are getting fixed up alongside other changes (EditEngine, third-generation APIs, etc).

I'm just going to close this since we've converted most of the Query classes by now and are fixing the remaining ones as adjacent work happens. These changes were just minor improvements to code clarity and there's no particular urgency to fully modernizing things, nor do we get to delete a bunch of code once we're done or reduce maintenance costs in a global way or anything like that.

This was indirectly resolved by the switch to prose diffs in T7643.

I think we got rid of this since it was kind of weird and overlapped a lot with tokens.

Actually, from T9899 it looks like we already require it anyway, so whatever.

This was resolved in conjunction with T8952.

I believe this is resolved with modern clustered repositories. secure has been spread across two hosts for some time now without encountering any of this.

Upstream-wise, T8250 should happen first.

We have config for this (remarkup.ignored-object-names) but the chatbot currently (by design) only uses the API, and there's no way to get this over the API.

I believe this was resolved as part of T8952:

Just reopening this so I don't forget about it since I agree about that last change.

Although this is cluster-related, it can be tested with a single database host and is probably not exceptionally difficult to handle better. Briefly:

In most cases, edits in Phabricator are preserved and displayed in a transaction log, similar to the one you are looking at right now on this task, where this very comment appears. The transaction log records a complete record of changes so it's easy to review what changed and when.

We really, truly need reproduction instructions that let us reproduce the problem in an environment we control. We're happy to accept this bug report and fix the underlying issue as soon as we're able to reproduce it.

I think we're on fairly firm technical footing on some specific changes, which I can probably lay the groundwork for and hand off to you to populate:

I agree with that (and actually believed we already did that, see T11485 for me claiming that this is the current behavior). We'll change this.

We haven't seen other reports of similar issues and can't reproduce this issue ourselves in a variety of production and development environments.

I'm going to close this since it's working as intended and was just based on a miscommunication -- the actions UI (above the comment text area) is not expected to show a preview of the effects of a change. Instead, the preview UI (below the comment text area) shows this preview information.

Actually, this is probably not T10968, although perhaps it's something similar -- possibly bad behavior when generating inline diffs or diff attachments for mail? It should normally be very difficult for a TransactionPublishWorker to generate mail side effects multiple times.

It's also vaguely desirable if the bulk processes (deploy/upgrade) can explicitly prefill the disk caches after mass-purging, since a bulk prefill is significantly more efficient than doing a readthrough fill moments later when the daemons restart. This only smooths out API burstiness during deploys, though.

Sorry, we don't offer help diagnosing problems. See Support Resources for a list of what we do and do not offer help with.

Some other things that could use updates:

After more thinking, I'm leaning heavily toward just doing a "display rename":

I used the new support code in connection with a manual instance rename (see T11413) and it appears to have worked.

I can't reproduce this. Here's what I did:

After D16427, I have an automated version of this working locally. It needs some more UI polish and I'm not going to try to get it in this week, but the support code (services dump / services export) will go out and then this can maybe go out next week or so.