According to curl/symbols-in-versions (this is a text file in the repository):

A possible issue is that letting cURL pick a protocol might lead to it selecting HTTP/1.0 in some cases (how/when could it possibly do this? Only by hard-coding known-broken hostnames, I think?), and forcing it to use HTTP/1.1 could break those cases, so maybe I'll go spelunking here. I also can't immediately find a date of introduction for CURL_HTTP_VERSION_1_1 from the documentation.

Another variation of this is "add more documentation", although I think the pattern around this one is more rarely a sort of "problem domain / solution domain mismatch" sort of issue and more often a "human communication" issue, usually with one of these two templates:

An adjacent issue is that PhabricatorMarkupCache is not currently marked as having cache persistence

loading a dump with missing data into a replica and then starting replication really causes issues

Use case from the thread is far off the beaten path ("The ideal version of the site on devices is a tiny version of the site on desktop"), so I'm not planning to put the time into investigating this unless substantially more interest emerges. I doubt the root issue is strictly a bug in Phabricator.

I'd like to understand why this option is useful before making any changes here (that is, why wasn't the user happy with the site as it appeared by default on their device)?

The "Merchant" profile screen is now somewhat inconsistent with the "Account" profile screen, and uses different icons for "Subscriptions" and "Orders".

We're also using inconsistent icons for "Order/Invoice/Receipt/Cart" in different interfaces. I'm going to standardize on this lovely purse, I think:

sourceMachine is currently exposed only in the UI.

./bin/user create

You can automate at least some administrative actions...

(You can automate at least some administrative actions at an "omnipotent" power level with bin/conduit call --method user.edit nowadays, too, although accountadmin operated with interactive prompts so it's unlikely anyone automated on top of it.)

Stuff to fix with subscriptions:

if this is really an issue we could likely throw a rate limit on the action

This is sort-of-quasi-intentional

A related issue is that when object A returns object B as an extended policy check and the user fails the extended policy check, the "PolicyException" dialog is misleading. It reads like this:

Actually, since the modern behavior is reasonable by default (the "Limit" field is not required, and defaults to empty, and the panel works properly if "Limit" is left blank), users have to explicitly set a limit to get any unintuitive behavior here. If they do, they still get a "View All Results" hint.

The bucket limit is currently implemented like this:

It would also be nice to figure out Phortune permissions better here since this is a good opportunity to vet everything.

See PHI1378, which is interested in "at least N", for N = 2.

There was one issue with this: bin/host stop --instance X (which is rarely used, and has no prior automated callers) used --force, which stops all daemons on the host. The recent changes to the --force flag in D20601 also had an indirect impact here. I fixed this and redeployed the repo tier.