The profiling in D20566 seems satisfactory, and has been useful in resolving or understanding a few performance-related issues.

• There is no way to pull custom field values with *.search. See above.
  • There is no way to edit non-custom field values with *.edit. The underlying transactions haven't been modularized yet; they should be, then EditEngine should get appropriate EditField definitions.
  • There's no way to identify which custom fields can be edited. This overlaps with T13248, but is also a Conduit API Console UI problem. The web UI should have some way to inspect parameter variations per object subtype for available subtypes.
    • As a workaround, you can try to edit an invalid field. The error message will identify valid fields.
  • There's no way to create steps with *.edit because you can't specify a step type. See T13449 for a general variation of the "type is required to initialize objects" problem.

HarbormasterBuildStepCoreCustomField emits no fields if a BuildStep has no attached Implementation object. This dates from D15352 and is conceptually reasonable ("don't crash if a build step exists but the implementation no longer does") but should probably be represented differently (e.g., an explicit "InvalidImplementation").

This appears fixed by D21484 (and @20after4 confirmed the fix on rPc0414732 -- thanks!) so I'm going to mark it as resolved.

See https://discourse.phabricator-community.org/t/strpos-throwing-in-phabricatorauthpasswordengine/4335, and D21477.

This synthetic script demonstrates the conceptual problem with FutureIterator:

I've marked D21461 as resolving this, since the new errors surface the particulars:

• D21457 fixes approximately 20 additional errors identified by the linter in phabricator/.

• D21454 fixes the specific issue in HTTPSFuture.

Check if arc lint catches this.

New user is told "install dinosaurs, you can trust epriestley.

Distribution would just be zip/tgz files for each package

I wonder if maintaining support for the builtin webserver is worthwhile -- I never use it, and I feel like I only see it referenced when users report bugs like this in the vein of "PHP builtin webserver has been completely broken for 13 years", which suggests it's probably not seeing very much use in the wild, either.

See also T9854: Support date/time reformatting in Remarkup for a related change, although I think neither feature directly impacts the other.

I think every other AWS interaction already uses v4, since D14978 (January 2016).

Internally, see also PHI1785.

Adding overflow-wrap: anywhere appears to fix this without breaking anything.