Skip to main content
This is 2026.9 documentation. Coverage here is incremental: a page exists only where 2026.9 differs or is newly documented. For any other topic, switch to Current (2026.8 and earlier) in the version selector.
If your function calls AttachResultToObjects (.NET) or attach_result_to_objects (Python) to flag individual objects, this page covers what happens when it runs against a model in the 2026.9 data model. This is a different problem from the results not being visible in the product UI yet — see Viewing Automate results in 2026.9 for that. This page is about the attach call itself, inside your function code.
There is no dedicated 2026.9 path for this API yet. What’s below is the current, accidental behavior of the compatibility projection Automate still receives through — not a supported or tested contract. Don’t build a function that depends on the specifics here holding.

​
What the attach call expects

Both SDKs key the objects you pass by id, the content-hashed Speckle object id, and carry applicationId alongside it:
Both raise if the object you pass has no id. Bundle-only 2026.9 versions have no content-hashed id at all — see Object model in 2026.9 — so this call should not work against them.

​
Why it doesn’t fail today

It doesn’t fail, but not because it was built to handle 2026.9 data. The objects your function receives for a bundle-only version still come back as a Base tree through Automate’s compatibility projection, and on that projection id is set equal to applicationId rather than left as a content hash. The dictionary above ends up keying an object by its own applicationId (ids[applicationId] = applicationId), which happens to satisfy the NotNull check and produce a result Automate can store. That’s a side effect of a decision made for a different problem (receive fidelity on the compatibility path), not a designed identity story for Automate. There is no committed spec for what this API looks like once Automate has its own bundle-era path, and no ticket number to point at yet.
An object your function constructs itself, or receives with neither id nor applicationId set, still throws. This isn’t limited to objects you read from the model — check any object you build in the function before attaching a result to it.

​
Results stored before a model was migrated

A run that finished before its model moved to the 2026.9 format stored its results against the content-hashed id. Migration doesn’t carry that hash into the migrated data: objects are identified by applicationId only, and an object that had no applicationId is keyed as spk: followed by its old hash. The stored results are kept as they were, but the ids inside them no longer match any object in the migrated model. Runs made after migration don’t have this problem, because they key results by applicationId. Re-run the automation against the migrated version to get results that line up with its objects.

​
What to do today

1

Make sure every object you attach results to has an applicationId

Objects you receive from a 2026.9-format model carry one. Objects your function constructs itself need applicationId set explicitly, or the attach call throws regardless of id.
2

Don't branch your function on id being a content hash

Don’t parse, compare, or cache by id expecting it to be a stable hash of the object’s content. For a bundle-only version it’s the same value as applicationId; for an object-graph version it’s still a real hash. Treat id as an opaque key either way.
3

Expect this to change without a migration path

Because this is compatibility-projection behavior and not a designed contract, a future Automate release can change how identity is keyed here without warning. Don’t build tooling that depends on id == applicationId continuing to hold.

​
FAQ

No. Viewing Automate results in 2026.9 is about the product UI not showing results yet. This page is about the attach call inside your function succeeding or failing. A function can attach results successfully and still have nothing visible in the viewer.
Automate’s bundle-era story is a separate, not-yet-scoped effort. There’s no spec, ADR, or ticket for it yet. This page will be replaced once one exists.
Not by id. Results stored before migration reference the old content-hashed id, which the migrated model no longer carries. Re-run the automation on the migrated version.
Better to make sure every object you attach a result to carries an applicationId before you call the attach method. Catching the exception hides a real problem: an object your function built without identity set.
Last modified on September 21, 2026