As of D19748, I'm not aware of any change of size X that requires more than 8X bytes of memory to parse. This isn't ideal, but it's a fair bit better than the 32X in the original report.

Presumably resolved elsewhere by D19503.

No clue how to reproduce this and we haven't seen anything similar since.

However, at some point I expect that we'll be unable to continue meaningfully improving the heuristic in general, and need to start adding rules based on the file language (for example, look for function signatures in C, keywords like "function" and "class" in PHP, patterns like ".prototype" in Javascript, lots of opening braces in Lisp, etc).

It's disappointing that this isn't supported.

For Phacility impact on the ExternalAccount changes so far, these callsites don't seem impacted yet (but might be worth keeping in mind in the future):

bin/config set should warn you when a stronger database value exists, and point you toward bin/config delete --database.

I think there's not much actionable here and this has all more or less resolved:

I'm going to dump everything I've got into master now that T13250 is mostly stabilized so it at least gets a couple of days of testing. I don't think I'm breaking anything in rP, but instances/ may require changes to instance initialization before this stuff can deploy.

There are a very small number of noncritical setQueryParam() callsites in arcanist/ (3), instances/ (1), and services/ (3). Of these 7 callsites, 6 are about building Diviner links. I'm going to leave these as-is for now to generally simplify rolling this out, but they should be updated before setQueryParam() is actually removed.

This would be incredibly useful for the things we are trying to do at WMF. I've gone so far as to duplicate lots of forms for each subtype and remove fields as needed. This results in N * N forms and it's not at all manageable beyond a very small number of sub-types.

I'm strongly considering allowing phutil_build_http_querystring() to build PHP-flavored query strings out of arrays again.

The error is less opaque in PHP 7.3:

This load chart for admin001, where steady state CPU load has dropped from ~20% to ~10%, suggests that the new scheme is legitimately more efficient and the deploy actually changed something:

I don't want to speak too soon, but the instances.state cache doesn't seem to have any other glaring issues. This load chart for admin001, where steady state CPU load has dropped from ~20% to ~10%, suggests that the new scheme is legitimately more efficient and the deploy actually changed something:

We can trivially serialize() before grabbing the lock to reduce the lock window. We could also write before grabbing the lock.

... and can take some real amount of time ...

Deploying the "instances.state" cache hit one issue on the repo tier:

When we reach getCustomFieldSpecificationForRole($role), via EditEngine, the $this object currently does not have a subtype set, so it can't make any decisions about which fields to expose. This appears to have a fairly surgical fix in EditEngine, but if there are like 10 more of these coming it might merit another look.