Do a better job of handling spec errors during schema adjustment


Do a better job of handling spec errors during schema adjustment

Ref T1191. Currently if a developer forgot to specify a column type, storage adjust aborts explosively mid-stream. Instead:

  • Make this a formal error with an unambiugous name/description instead of something you sort of infer by seeing "<unknown>".
  • Make this error prevent generation of adjustment warnings, so we don't try to ALTER TABLE t CHANGE COLUMN c <unknown>, which is nonsense.
  • When schemata errors exist, surface them prominiently in storage adjust.


  • Once storage upgrade runs storage adjust automatically (soon), this will make it relatively difficult to miss these errors.
  • Letting these errors slip through no longer escalates into a more severe issue.

Test Plan:
Commented out the recent mailKey spec and ran storage adjust:

$ ./bin/storage adjust --force
Verifying database schemata...
Found no adjustments for schemata.

Target                                            Error
phabricator2_phriction.phriction_document.mailKey Column Has No Specification


The schemata have serious errors (detailed above) which the adjustment
workflow can not fix.

If you are not developing Phabricator itself, report this issue to the

If you are developing Phabricator, these errors usually indicate that your
schema specifications do not agree with the schemata your code actually

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T1191

Differential Revision: https://secure.phabricator.com/D10771