Follow-up to our local-preview post. We tried to deploy the same SuperRepo (three code-born types,
two function-backed actions, three TypeScript v2 functions, a React app) that imports ~70 object
types read-only from an existing Ontology Manager ontology. The imports are mandatory install
inputs, which makes sense — but we could not get them to validate in an install draft. We ran
draft-only checks (upload signed bundle → install draft → read validations → delete draft) and
have parked the SuperRepo route for this app for now. Three findings, in case they help:
**Environment:** foundry-cli 0.253.0 · `@osdk/maker` 0.67.0 · `@osdk/maker-experimental` 0.61.0 ·
`@osdk/maker-import` 0.37.0 · lock written by `foundry import ontology --objects …`.
**1. Imported properties reference shared property types the bundle never declares.**
Every imported property backed by an SPT gets `“sharedPropertyType”: “”` in its input
shape (135 references in our bundle), but no block declares an SPT input with any of those shape
ids. The draft reports `propertyTypeShapeError` / `sharedPropertyTypeReferenceUnresolvable`
(`expected: `, `actual: ri.ontology.main.shared-property.…`) with the hint "likely due
to input mapping being incomplete", but no mapping can resolve it. Importing the SPTs with
`–shared-property-types` changes nothing in the bundle (identical manifest). Workaround that
validated: strip `sharedPropertyTypeMapping` from the lock file, so the properties are declared
as plain properties — the imported type then maps cleanly onto the live SPT-backed properties.
**2. Many-to-many link input shapes use alphabetical side order, not the live A/B sides.**
The lock file (`OntologyFullMetadata`) records each link per object type but not which side is
A. The bundle declares every imported many-to-many link with the alphabetically first object type
as side A; for 11 of our 24 links that is the reverse of the live link (e.g. live A = `device`,
B = `customer`; bundle A = `customer`). The draft then reports both
“`` requires Device, but Customer was provided” and "`` requires Customer, but Device
was provided". We rewrote those shapes to the live orientation inside `blockset.zip` and
re-signed with `foundry bundle store`; the input names flipped as expected but **the same pair of
errors remained**, so orientation may not be the whole story. One-to-many links and object types
validate. Questions: is there a supported way to import many-to-many links today, and does the
lock need to carry side information?
**3. Intermediary (object-backed) many-to-many links fail as `MANY_TO_MANY`.**
`unexpectedLink … actual INTERMEDIARY expected MANY_TO_MANY`. The shape extractor in
`maker-experimental` has an `intermediary` case, but imported intermediary links arrive as plain
many-to-many. We pruned them from the lock (our app writes the intermediary objects directly), which
worked.
**Also noted (smaller):**
- 174 mandatory inputs are never auto-mapped. Per-input presets exist, but bulk-set maps every
selected input to one target, and “Auto-select from folder” finds nothing when the imported types
live in the ontology’s own container rather than in a project. A "use preset for each selected
input" bulk action would make large imports practical.
- `BlockMustBeRepackagedWithLatestMarketplaceVersion` on the Functions Repository block is shown as
“Validation error” in the draft sidebar but classed NON_BLOCKING (install succeeds).
Happy to share a sanitised manifest excerpt for any of these. Thanks again for the quick fix on the
underscore link ids.