What causes "No file transform with key "%s" exists." in phacility/phabricator?

List the valid keys and pick the right one: var_dump(array_keys(PhabricatorFileTransform::getAllTransforms()));

phacility/phabricator · error · Exception

No file transform with key "%s" exists.

Error message

No file transform with key "%s" exists.

What it means

PhabricatorFileTransform::getTransformByKey($key) looks the key up in the class-map of all registered transforms (built via getAllTransforms() with PhutilClassMapQuery, generateTransforms expansion, and getTransformKey() uniqueness). The given key matched nothing, so no such transform exists and the lookup throws rather than returning null.

Source

Thrown at src/applications/files/transform/PhabricatorFileTransform.php:43

    }

    return $this->getDefaultTransform($file);
  }

  public static function getAllTransforms() {
    return id(new PhutilClassMapQuery())
      ->setAncestorClass(__CLASS__)
      ->setExpandMethod('generateTransforms')
      ->setUniqueMethod('getTransformKey')
      ->execute();
  }

  public static function getTransformByKey($key) {
    $all = self::getAllTransforms();

    $xform = idx($all, $key);
    if (!$xform) {
      throw new Exception(
        pht(
          'No file transform with key "%s" exists.',
          $key));
    }

    return $xform;
  }

}

View on GitHub (pinned to 5720a38cfe)

Solutions

List the valid keys and pick the right one: var_dump(array_keys(PhabricatorFileTransform::getAllTransforms()));
Fix typos/casing — keys are exact strings like 'thumb-140x140' or 'profile-100x100'.
If the key should come from a custom subclass, verify the class extends PhabricatorFileTransform, is loadable, and its getTransformKey() matches; check for uniqueness collisions silently dropping it.

Example fix

// before
$xform = PhabricatorFileTransform::getTransformByKey('thumbnail-140');

// after
$xform = PhabricatorFileTransform::getTransformByKey('thumb-140x140');

Defensive patterns

Strategy: type-guard

Validate before calling

$all = PhabricatorFileTransform::getAllTransforms();
if (idx($all, $key) === null) {
  // unknown key: log and use a safe default instead of throwing
  $key = 'thumb-140x140';
}
$xform = PhabricatorFileTransform::getTransformByKey($key);

Type guard

function isValidTransformKey(string $key): bool {
  return idx(PhabricatorFileTransform::getAllTransforms(), $key) !== null;
}

Try / catch

try {
  $xform = PhabricatorFileTransform::getTransformByKey($key);
} catch (Exception $ex) {
  $xform = PhabricatorFileTransform::getTransformByKey('thumb-140x140');
}

Prevention

Never hard-code transform keys blindly — enumerate them via getAllTransforms() and assert membership in a test.
After upgrading Phabricator, re-check that keys your code references still exist.
For custom transforms, unit-test getTransformKey() so renames are caught at CI time.

When it happens

Trigger: Calling PhabricatorFileTransform::getTransformByKey('profile-100x100') with a misspelled or outdated key; requesting a key only produced by generateTransforms() of a custom subclass that is not installed/enabled; a key renamed between Phabricator versions.

Common situations: Hard-coded transform keys in custom code or migrations that drift from the codebase after an upgrade; typos in configuration (e.g. a default-avatar transform setting); custom transform classes whose getTransformKey() changed or which fail to load due to a syntax error.

Related errors

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