invoke-ai/InvokeAI · error · Exception

Unknown lora: {lora.lora.key}!

Error message

Unknown lora: {lora.lora.key}!

What it means

When collecting LoRAs attached to the loader's inputs, the invocation re-validates each LoRA key against the model manager and raises a plain Exception if the key no longer exists. Unlike error 563 (the primary LoRA field), this fires for LoRAs already attached to the transformer or Qwen3 encoder fields whose records have vanished.

Source

Thrown at invokeai/app/invocations/z_image_lora_loader.py:153

    def invoke(self, context: InvocationContext) -> ZImageLoRALoaderOutput:
        output = ZImageLoRALoaderOutput()
        loras = self.loras if isinstance(self.loras, list) else [self.loras]
        added_loras: list[str] = []

        if self.transformer is not None:
            output.transformer = self.transformer.model_copy(deep=True)

        if self.qwen3_encoder is not None:
            output.qwen3_encoder = self.qwen3_encoder.model_copy(deep=True)

        for lora in loras:
            if lora is None:
                continue
            if lora.lora.key in added_loras:
                continue

            if not context.models.exists(lora.lora.key):
                raise Exception(f"Unknown lora: {lora.lora.key}!")

            if lora.lora.base is not BaseModelType.ZImage:
                raise ValueError(
                    f"LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.lora.base else 'unknown'} models, "
                    "not Z-Image models. Ensure you are using a Z-Image compatible LoRA."
                )

            # Warn on variant mismatch between LoRA and transformer.
            lora_config = context.models.get_config(lora.lora.key)
            lora_variant = getattr(lora_config, "variant", None)
            if lora_variant and self.transformer is not None:
                transformer_config = context.models.get_config(self.transformer.transformer.key)
                transformer_variant = getattr(transformer_config, "variant", None)
                if transformer_variant and lora_variant != transformer_variant:
                    context.logger.warning(
                        f"LoRA variant mismatch: LoRA '{lora_config.name}' is for {lora_variant.value} "
                        f"but transformer is {transformer_variant.value}. This may cause unexpected results."
                    )

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Re-install the missing LoRA so its key exists again.
  2. Open the loader node and re-select/replace the dead LoRA entry on the transformer or encoder input.
  3. Re-scan the models directory so orphaned references are reported and fixable in the UI.

Example fix

// before
transformer.loras = [LoRAField(lora=ModelIdentifierField(key='gone-key'))]
// after
transformer.loras = [LoRAField(lora=ModelIdentifierField(key='installed-key'))]
Defensive patterns

Strategy: validation

Validate before calling

for l in list(loader.transformer.loras if loader.transformer else []) + list(loader.qwen3_encoder.loras if loader.qwen3_encoder else []):
    if not context.models.exists(l.lora.key):
        raise ValueError(f"Attached LoRA {l.lora.key} is missing; re-select it before invoking")

Try / catch

try:
    out = z_image_lora_loader.invoke(context)
except Exception as e:
    if str(e).startswith("Unknown lora:"):
        context.logger.error(f"{e} - reinstall the LoRA or remove the stale entry from the transformer/encoder input.")
    else:
        raise

Prevention

When it happens

Trigger: During ZImageLoRALoaderOutput construction, iterating self.transformer.loras / self.qwen3_encoder.loras and encountering an entry whose lora.lora.key fails context.models.exists().

Common situations: A LoRA referenced by a saved graph was deleted or its model record was purged; reinstalling InvokeAI with a different models.db; shared workflow imports with foreign keys.

Related errors

AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/3f0462b7cbf4410c. Report an issue: GitHub.