invoke-ai/InvokeAI · error · Exception

Unknown lora: {lora.lora.key}!

Error message

Unknown lora: {lora.lora.key}!

What it means

The FLUX.2 dev LoRA collection loader iterates LoRAs accumulated on the transformer and encoder and verifies each still exists in the model store before patching. If a key is missing it raises Exception (not ValueError) with the unknown key.

Source

Thrown at invokeai/app/invocations/flux2_dev_lora_loader.py:161

    )

    def invoke(self, context: InvocationContext) -> Flux2DevLoRALoaderOutput:
        output = Flux2DevLoRALoaderOutput()
        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.mistral_encoder is not None:
            output.mistral_encoder = self.mistral_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}!")

            # A FLUX.1 LoRA (base `flux`) has no variant field, so `_assert_dev_lora` below
            # would pass it through to model patching where it fails late. Fail fast here with
            # a clear error instead, matching the Klein collection loader. (A bare `assert`
            # would also be stripped under `python -O`.)
            if lora.lora.base is not BaseModelType.Flux2:
                raise ValueError(
                    f"LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.lora.base else 'unknown'} models, "
                    "not FLUX.2 [dev] models. Ensure you are using a FLUX.2 [dev] compatible LoRA."
                )

            lora_config = context.models.get_config(lora.lora.key)
            # Reject variant-mismatched LoRAs, matching the single-LoRA loader above.
            _assert_dev_lora(context, lora_config)

            added_loras.append(lora.lora.key)

            if self.transformer is not None and output.transformer is not None:

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Reinstall the missing LoRA via Model Manager so the key resolves
  2. Rebuild the LoRA loader chain selecting only currently installed LoRAs
  3. Pre-check every lora key with context.models.exists before invoking the pager and prune missing entries

Example fix

# before
loras = existing_chain_loras  # contains an uninstalled key
# after
loras = [l for l in existing_chain_loras if context.models.exists(l.lora.key)]
Defensive patterns

Strategy: validation

Validate before calling

missing = [l.lora.key for l in loras if l is not None and not context.models.exists(l.lora.key)]
if missing:
    raise ValueError(f'missing loras: {missing}')

Try / catch

try:
    out = pager.invoke(context)
except Exception as e:
    if str(e).startswith('Unknown lora:'):
        loras = [l for l in loras if context.models.exists(l.lora.key)]
        out = pager.invoke(context)
    else:
        raise

Prevention

When it happens

Trigger: invoking Flux2DevLoRAModelPagerInvocation (collection loader) where any LoRAField in the transformer/encoder loras lists resolves to a key absent from context.models — model uninstalled between building the chain and running it.

Common situations: Stale saved workflows referencing deleted models; shared graphs from machines with different model sets; interrupted model imports.

Related errors


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