phacility/phabricator · error · Exception

Subtype configuration is invalid: there is no subtype define

Error message

Subtype configuration is invalid: there is no subtype defined with key "%s". This subtype is required and must be defined.

What it means

After validating every subtype entry, validateConfiguration() requires that the built-in default subtype key (PhabricatorEditEngineSubtype::SUBTYPE_DEFAULT, the literal string "default") is defined in the list. Objects without an explicit subtype and all default form behavior depend on it, so a config lacking "default" is rejected.

Source

Thrown at src/applications/transactions/editengine/PhabricatorEditEngineSubtype.php:229

              $key));
        }
      }

      $fields = idx($value, 'fields');
      if ($fields) {
        foreach ($fields as $field_key => $configuration) {
          PhutilTypeSpec::checkMap(
            $configuration,
            array(
              'disabled' => 'optional bool',
              'name' => 'optional string',
            ));
        }
      }
    }

    if (!isset($map[self::SUBTYPE_DEFAULT])) {
      throw new Exception(
        pht(
          'Subtype configuration is invalid: there is no subtype defined '.
          'with key "%s". This subtype is required and must be defined.',
          self::SUBTYPE_DEFAULT));
    }

    foreach ($config as $value) {
      $key = idx($value, 'key');

      $mutations = idx($value, 'mutations');
      if (!$mutations) {
        continue;
      }

      foreach ($mutations as $mutation) {
        if (!isset($map[$mutation])) {
          throw new Exception(
            pht(

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Add an entry {"key": "default", "name": "Default"} to the subtype list
  2. Keep it even if all real work happens on custom subtypes — the engine depends on the key existing
  3. If you don't want users picking it, keep the definition but exclude it from child forms / mark mutations appropriately rather than deleting it

Example fix

// before
[
  { "key": "bug", "name": "Bug" },
  { "key": "feature", "name": "Feature" }
]
// Exception: there is no subtype defined with key "default".

// after
[
  { "key": "default", "name": "Default" },
  { "key": "bug", "name": "Bug" },
  { "key": "feature", "name": "Feature" }
]
Defensive patterns

Strategy: validation

Validate before calling

$keys = array_column($config, 'key');
if (!in_array('default', $keys, true)) {
  // reject before saving: the required 'default' subtype is missing
}

Type guard

function defaultSubtypePresent(array $config) {
  return in_array('default', array_column($config, 'key'), true);
}

Prevention

When it happens

Trigger: Saving a subtype list that defines custom subtypes (bug, feature, ...) but omits an entry with "key": "default"; removing the default entry intentionally to 'clean up' the list.

Common situations: First-time subtype configuration copied from a blog post that shows only custom subtypes; refactor that drops 'unused' entries; migration tooling generating only business subtypes.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors


AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/6a6c0948327e1543. Report an issue: GitHub.