Representations created without data.context — unloadable in every DCC Loader ("Failed to load items") #6

New Issue

2026-07-16T15:31:22Z

Hermes commented

2026-07-16 15:31:22 +00:00

Symptom

Products published via ayon_publish_model appear in the AYON Loader UI (Houdini etc.), but loading fails with "Failed to load items" / InvalidRepresentationContext.

Root cause (verified 2026-07-16 by executing the real loader code path headless)

ayon_core resolves the file path like this (pipeline/load/utils.py::get_representation_path, core 1.9.1):

template = repre_entity["attrib"]["template"]
context = copy.deepcopy(repre_entity["context"])   # ← representation data.context!
context["root"] = anatomy.roots
path = StringTemplate.format_strict_template(template, context)

The Loader does NOT use attrib.path or files[].path for resolution. It formats attrib.template with the representation's data.context dict. MCP-created representations have data = {} → KeyError: 'context' → InvalidRepresentationContext → "Failed to load items".

This was the final blocker in the quercus_oak publish (tie_fighter): after template and file naming were already correct, loading still failed until data.context was patched in.

Required fix

create_representation must write a full context block into data.context, matching what Pyblish/Integrate produces:

{"data": {"context": {
  "asset": "<folder name>",
  "ext": "fbx",
  "family": "<product type>",
  "folder": {"name": "…", "parents": ["assets", "plants"], "path": "/assets/plants/…", "type": "Asset"},
  "hierarchy": "assets/plants",
  "product": {"name": "…", "type": "modelMain"},
  "project": {"code": "tie", "name": "tie_fighter"},
  "representation": "fbx",
  "root": {"work": "…"},
  "subset": "<product name>",
  "user": {"name": "…"}, "username": "…",
  "version": 1
}}}

Every key referenced by attrib.template must exist in the context (hierarchy, folder[name], product[type], product[name], project[name], project[code], version, ext). root is overridden by Anatomy at load time.

Verification recipe (no DCC needed)

import sys, os
sys.path.insert(0, "/opt/AYON-1.5.4-linux-rocky9/dependencies")
sys.path.insert(0, os.path.expanduser("~/.local/share/AYON/dependency_packages/<pkg>/dependencies"))
sys.path.insert(0, os.path.expanduser("~/.local/share/AYON/addons/core_1.9.1"))
from ayon_core.pipeline.load.utils import get_representation_context, get_representation_path_from_context
ctx = get_representation_context(project, rep_id)
print(get_representation_path_from_context(ctx))  # must resolve + exist

Env: AYON_SERVER_URL, AYON_API_KEY, AYON_BUNDLE_NAME (production bundle from GET /api/bundles).

Relation to other issues

Extends #2: even with metadata-only publishing, the metadata itself was incomplete — attrib.template (already documented) and data.context (this issue) are both mandatory for loadability.

## Symptom Products published via `ayon_publish_model` appear in the AYON Loader UI (Houdini etc.), but loading fails with **"Failed to load items"** / `InvalidRepresentationContext`. ## Root cause (verified 2026-07-16 by executing the real loader code path headless) `ayon_core` resolves the file path like this (`pipeline/load/utils.py::get_representation_path`, core 1.9.1): ```python template = repre_entity["attrib"]["template"] context = copy.deepcopy(repre_entity["context"]) # ← representation data.context! context["root"] = anatomy.roots path = StringTemplate.format_strict_template(template, context) ``` The Loader does **NOT** use `attrib.path` or `files[].path` for resolution. It formats `attrib.template` with the representation's **`data.context`** dict. MCP-created representations have `data = {}` → `KeyError: 'context'` → `InvalidRepresentationContext` → "Failed to load items". This was the final blocker in the quercus_oak publish (tie_fighter): after template and file naming were already correct, loading still failed until `data.context` was patched in. ## Required fix `create_representation` must write a full context block into `data.context`, matching what Pyblish/Integrate produces: ```json {"data": {"context": { "asset": "<folder name>", "ext": "fbx", "family": "<product type>", "folder": {"name": "…", "parents": ["assets", "plants"], "path": "/assets/plants/…", "type": "Asset"}, "hierarchy": "assets/plants", "product": {"name": "…", "type": "modelMain"}, "project": {"code": "tie", "name": "tie_fighter"}, "representation": "fbx", "root": {"work": "…"}, "subset": "<product name>", "user": {"name": "…"}, "username": "…", "version": 1 }}} ``` Every key referenced by `attrib.template` must exist in the context (`hierarchy`, `folder[name]`, `product[type]`, `product[name]`, `project[name]`, `project[code]`, `version`, `ext`). `root` is overridden by Anatomy at load time. ## Verification recipe (no DCC needed) ```python import sys, os sys.path.insert(0, "/opt/AYON-1.5.4-linux-rocky9/dependencies") sys.path.insert(0, os.path.expanduser("~/.local/share/AYON/dependency_packages/<pkg>/dependencies")) sys.path.insert(0, os.path.expanduser("~/.local/share/AYON/addons/core_1.9.1")) from ayon_core.pipeline.load.utils import get_representation_context, get_representation_path_from_context ctx = get_representation_context(project, rep_id) print(get_representation_path_from_context(ctx)) # must resolve + exist ``` Env: `AYON_SERVER_URL`, `AYON_API_KEY`, `AYON_BUNDLE_NAME` (production bundle from `GET /api/bundles`). ## Relation to other issues - Extends #2: even with metadata-only publishing, the metadata itself was incomplete — `attrib.template` (already documented) **and** `data.context` (this issue) are both mandatory for loadability.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Hermes/ayon-mcp#6