invoke-ai/InvokeAI · error · ValueError

Key {key} does not match parsing tree {parsing_tree}.

Error message

Key {key} does not match parsing tree {parsing_tree}.

What it means

insert_periods_into_kohya_key rebuilds dotted keys by walking a parsing tree (generated from known keys) that maps underscore-joined key segments. If after consuming the whole key a non-empty segment remains unmatched, the key cannot be parsed against the tree and ValueError is raised. This catches Kohya/OneTrainer keys whose module names differ from those the tree was built from.

Source

Thrown at invokeai/backend/patches/lora_conversions/kohya_key_utils.py:56

    for part in parts:
        if len(current_part) > 0:
            current_part = current_part + "_"
        current_part += part

        if current_part in current_tree:
            # Match found.
            current_tree = current_tree[current_part]
            result_parts.append(current_part)
            current_part = ""
        elif current_part.isnumeric() and INDEX_PLACEHOLDER in current_tree:
            # Match found with index placeholder.
            current_tree = current_tree[INDEX_PLACEHOLDER]
            result_parts.append(current_part)
            current_part = ""

    if len(current_part) > 0:
        raise ValueError(f"Key {key} does not match parsing tree {parsing_tree}.")

    return ".".join(result_parts)


def generate_kohya_parsing_tree_from_keys(keys: Iterable[str]) -> ParsingTree:
    """Generate a parsing tree from a list of keys.

    Example:
    ```
    keys = [
        "module_a.module_b.0.attn.to_k",
        "module_a.module_b.1.attn.to_k",
        "module_a.module_c.proj",
    ]

    tree = generate_kohya_parsing_tree_from_keys(keys)
    > {
    >     "module_a": {

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Rebuild the parsing tree with generate_kohya_parsing_tree_from_keys including all keys from the LoRA before parsing.
2. Extend the parsing tree / add the new module naming to the key-conversion logic and upstream it.
3. Skip or remap the unparseable key if its LoRA component is not required.

Example fix

// before
tree = generate_kohya_parsing_tree_from_keys(sd_subset_keys)
key = insert_periods_into_kohya_key(foreign_key, tree)  # ValueError
// after
tree = generate_kohya_parsing_tree_from_keys(sd_subset_keys + [foreign_key])
key = insert_periods_into_kohya_key(foreign_key, tree)

from invokeai.backend.patches.lora_conversions.kohya_key_utils import generate_kohya_parsing_tree_from_keys, insert_periods_into_kohya_key
tree = generate_kohya_parsing_tree_from_keys(all_keys)
for k in all_keys:
    try:
        insert_periods_into_kohya_key(k, tree)
    except ValueError as e:
        raise ValueError(f"pre-check failed: {e}")

try:
    dotted = insert_periods_into_kohya_key(key, tree)
except ValueError as e:
    logger.error("kohya key unparseable: %s", e)
    dotted = None

When it happens

Trigger: Calling insert_periods_into_kohya_key (directly or via OneTrainer transformer conversion / Krea2 unflattening) with a key containing a segment sequence absent from the parsing tree, or a key longer/deeper than any key used to build the tree.

Common situations: LoRAs from a newer trainer with module names unknown to the tree; building the tree from a subset of keys then parsing others; tests like test_insert_periods_into_kohya_key_invalid_key/too_long exercise exactly these cases.

Related errors

• Key '{k}' does not match the expected pattern for FLUX LoRA
• Unsupported lora format: {state_dict.keys()}
• Layer '{layer_name}' does not match the expected pattern for
• Key '{key}' does not match the expected pattern for xlabs FL
• Krea-2 LoRA has conflicting layers that normalize to the sam

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