Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions PYEGERIA_ISSUES.md
Original file line number Diff line number Diff line change
Expand Up @@ -622,6 +622,72 @@ evidence for both dates — not yet deleted.

---

### ISSUE-85: No REST endpoint exists to create a `SolutionPort` element — only attach/detach/delegation relationships are exposed

**Status:** open, confirmed Egeria-side gap 2026-09-03. Found by a
consumer (trellis/Resource Explorer, designing a `PortMaterializer` for
architecture-recovery proposals) hitting the same shape of gap ISSUE-84
turned out not to be: this time the `.http` ground truth's absence really
does match the live server, not a stale/incomplete `.http` file.

**Confirmed at every layer:**
- `pyegeria/omvs/solution_architect.py`: `link_solution_component_port`
(attach an *existing* port to a component), `link_solution_port_delegation`
(port-to-port delegation), and both detach counterparts exist. No
`create_solution_port`/`_async_create_solution_port` anywhere.
- `Egeria-api-solution-architect.http`: only `.../solution-components/
{guid}/solution-ports/{guid}/attach|detach` and `.../solution-ports/
{guid}/port-delegations/{guid}/attach|detach`. No `POST .../solution-ports`
create path.
- `md_processing/data/compact_commands/commands_solution_architect_compact.json`:
only `Link Solution Component Port`/`Link Solution Port Delegation`. No
`Create Solution Port` command.
- `pyegeria/models/models.py`: no `SolutionPortProperties` model at all —
so even the generic fallback route has nothing typed to build a body
against.

**Live-verified not just a stale-`.http`-file case** (the precedent this
repo already has for that shape of false alarm — see the multi-link audit
above, where 3 of 4 similarly-unwrapped relationship types turned out to
have zero real endpoint on live-server inspection while others did):
`dwolfson-1b`/trellis fetched the full live OpenAPI spec directly
(`GET /v3/api-docs`, 2.39MB) and searched every path containing "port" —
30 POST paths matched, every one of them attach/detach (component-port,
port-delegation, even a generic process-ports attach under a different
`{urlMarker}` service). Zero creation endpoints anywhere in the spec.
This confirms the `.http` ground truth exactly; not a documentation gap.

**The generic fallback exists but isn't usable without guessing:**
`/servers/{serverName}/api/open-metadata/{urlMarker}/metadata-elements`
(`MetadataExpert.create_metadata_element`,
`NewOpenMetadataElementRequestBody`) is real and live-confirmed present,
with a top-level `type_name` field that could carry `"SolutionPort"`. But
per this file's own `pyegeria/models/models.py` gotcha, that endpoint's
`properties` field needs the verbose nested `ElementProperties`/
`propertyValueMap` shape server-side, not the flat dict every bespoke
wrapper uses — and with no `SolutionPortProperties` model to check
property names against, building that body means hand-guessing what
properties a `SolutionPort` actually takes. Consistent with this repo's
established practice (see the multi-link audit's "left unbuilt rather
than guessing at undocumented URLs or building against the awkward
generic path speculatively") — not attempted.

**Nothing to fix in pyegeria until Egeria adds a real create endpoint.**
Once one exists, the follow-on work is small and well-precedented: a
`create_solution_port`/`_async_create_solution_port` wrapper in
`SolutionArchitect` following the exact pattern ISSUE-84 just corrected
(`NewElementRequestBody` + `contentStatus` inside `properties`, no
fictional separate request-body class), plus a `Create Solution Port`
Dr.Egeria compact command — the family's registration plumbing in
`register_solution_architect_processors()` (`md_processing/dr_egeria.py`)
already handles this shape of addition with no new routing logic needed.

**Not blocking anything urgent** on the trellis/Resource Explorer side —
they're holding real port materialization until this exists server-side
(tracked as their own Backlog item 8), or until a workaround surfaces.

---

## Open pyegeria items (including follow-ons blocked on an Egeria fix)

Actionable in this repo. Some of these are fully blocked today — waiting
Expand Down
Loading