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
- Add an entry {"key": "default", "name": "Default"} to the subtype list
- Keep it even if all real work happens on custom subtypes — the engine depends on the key existing
- 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
- Always include {"key": "default", "name": "Default"} — the engine requires it
- Hide unwanted defaults via forms/mutations instead of deleting the entry
- Validate the whole config (this rule plus key rules, uniqueness, names) before saving
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
- Subtype "%s" is not valid: subtype keys must be no longer th
- Subtype "%s" is not valid: subtype keys must have a minimum
- Subtype "%s" is not valid: subtype keys may only contain low
- Subtype configuration is invalid: it must be a list of subty
- Subtype configuration is invalid: two subtypes use the same
AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21).
Data as JSON: /api/errors/6a6c0948327e1543.
Report an issue: GitHub.