Skip to content

Commit d52f394

Browse files
committed
fix(automated-curation): ISSUE-83 skipClassifiedElements empty-string bug
get_technology_type_elements(get_templates=True) built skipClassifiedElements as [skip_templates] where skip_templates was "" when get_templates=True -- sending a one-element list containing an empty string, not an empty list. Egeria correctly rejects the empty classification name (OMAG-COMMON-400-018 "The type name ... is not recognized"), so every call with get_templates=True fails outright. Found via a user report: a known live RelationalDatabase asset didn't appear browsing Technology Types -> Postgres Relational Databases in egeria-workspaces' Tech Catalog, even though it was directly retrievable by GUID and correctly tagged (deployedImplementationType: "PostgreSQL Relational Database"). The failure is masked downstream -- egeria-workspaces' tech_catalog_handler.py calls this with get_templates=True unconditionally and treats any "400" in the error message as "no elements found," so the whole listing silently renders empty instead of erroring. Fix: skip_classified_elements = [] if get_templates else ["Template"]. Also corrected the method's docstring sample body, which showed the same [""] value as if it were correct usage. Live-verified end-to-end, not just unit-tested: live-patched into quickstart-pyegeria-web's installed pyegeria (docker cp + restart, diff-confirmed), then curled the actual production route -- it now returns the previously-missing asset correctly (15 items with templates included vs. 14 without, consistent). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
1 parent d1b7aac commit d52f394

2 files changed

Lines changed: 66 additions & 3 deletions

File tree

‎PYEGERIA_ISSUES.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -681,6 +681,59 @@ if type_name:
681681
**Nothing left open here.** Fixed, released (pyegeria 6.1.7), and live-verified
682682
end-to-end against the original real-world repro, not just unit-tested.
683683

684+
### ISSUE-83: `AutomatedCuration.get_technology_type_elements(get_templates=True)` sends `skipClassifiedElements: [""]` (a list containing an empty string) instead of `[]` — Egeria rejects the empty classification name, so every Tech Catalog technology-type listing renders silently empty instead of erroring
685+
686+
**Status:** fixed and live-verified 2026-09-02.
687+
688+
**Root cause:** `_async_get_technology_type_elements`
689+
(`pyegeria/omvs/automated_curation.py`) built `skipClassifiedElements` as
690+
`[skip_templates]` where `skip_templates = "Template" if not get_templates
691+
else ""` — when `get_templates=True` (the caller wants templates
692+
*included*, i.e. skip nothing), this sent `["", ]`, a one-element list
693+
containing an empty string, not `[]`. Egeria's server correctly rejects an
694+
empty classification name:
695+
696+
```
697+
OMAG-COMMON-400-018 The type name passed on method findMetadataElements
698+
of service Open Metadata Store Services is not recognized
699+
```
700+
701+
**Why it went unnoticed:** the failure is masked downstream. `egeria-
702+
workspaces`' `tech_catalog_handler.py` calls this with `get_templates=True`
703+
unconditionally (`get_tech_type_elements`), and its own exception handler
704+
treats any error message containing `"400"` as "no elements found," so the
705+
whole Tech Catalog "Elements" listing for a technology type renders as an
706+
honest-looking, self-consistent **empty list** instead of surfacing the
707+
real 500. Any caller with a similar "400 means empty" convenience handler
708+
would hit the same masking.
709+
710+
**Found by:** a user report — a known live `RelationalDatabase` asset
711+
(`deployedImplementationType: "PostgreSQL Relational Database"`, confirmed
712+
present via direct GUID lookup) did not appear browsing Technology Types →
713+
Postgres Relational Databases in `egeria-workspaces`' Tech Catalog.
714+
Reproducing the exact call chain (`AutomatedCuration.
715+
get_technology_type_elements(filter_string="PostgreSQL Relational
716+
Database", get_templates=True, ...)`, the parameters `tech_catalog_handler.
717+
py`'s `/api/tech-catalog/tech-types/{qualified_name}/elements` route
718+
actually uses) reproduced the 500 directly; the same call with
719+
`get_templates=False` succeeded and returned the asset correctly (14
720+
items) — isolating the defect to the `get_templates=True` branch
721+
specifically, not a metadata/zone/visibility problem on the asset itself.
722+
723+
**Fix:** `skip_classified_elements = [] if get_templates else ["Template"]`
724+
— an empty list (skip nothing) when templates should be included, a
725+
one-element list naming the real `Template` classification to skip
726+
otherwise. Also corrected the method's own docstring sample JSON body,
727+
which showed the same `[""]` value as if it were correct usage.
728+
729+
**Live-verified end-to-end**, not just unit-tested: live-patched into
730+
`quickstart-pyegeria-web`'s installed pyegeria (`docker cp` + restart,
731+
diff-confirmed byte-identical), then curled the actual production route —
732+
`GET /api/tech-catalog/tech-types/PostgreSQL%20Relational%20Database/
733+
elements?display_name=PostgreSQL%20Relational%20Database` — which now
734+
returns the previously-missing asset as the first result, alongside the
735+
other 14 (15 total with templates included, vs. 14 without — consistent).
736+
684737
### ISSUE-81: `migrate_question_specs.py` links Perspective↔Question via the wrong relationship type (`AssignmentScope`, not `ScopedBy`) — every bootstrap-migrated perspective silently relies on a filename-inference fallback instead
685738

686739
**Status:** fixed 2026-08-28 — script corrected (see "Fix landed" below);

‎pyegeria/omvs/automated_curation.py‎

Lines changed: 13 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -5350,14 +5350,24 @@ async def _async_get_technology_type_elements(
53505350
"class": "FilterRequestBody",
53515351
"filter": "File System Directory",
53525352
"effectiveTime": "2023-10-27T10:00:00",
5353-
"skipClassifiedElements": [""],
5353+
"skipClassifiedElements": ["Template"],
53545354
"startFrom": 0,
53555355
"pageSize": 100
53565356
}
53575357
```
53585358
"""
53595359

5360-
skip_templates = "Template" if not get_templates else ""
5360+
# ISSUE-83: skipClassifiedElements must be [] to skip nothing (include
5361+
# templates), not [""] -- a list containing an empty string is sent to
5362+
# Egeria as a request to skip elements classified with an empty-string
5363+
# classification name, which the server correctly rejects with
5364+
# OMAG-COMMON-400-018 "The type name ... is not recognized". That
5365+
# made every get_technology_type_elements(get_templates=True) call
5366+
# fail outright, silently masked downstream by callers that treat any
5367+
# 400 as "no elements found" -- e.g. an entire Tech Catalog technology
5368+
# type listing renders as empty (self-consistent, easy to mistake for
5369+
# correct) instead of surfacing the real error.
5370+
skip_classified_elements = [] if get_templates else ["Template"]
53615371
validate_name(filter_string)
53625372

53635373
url = (
@@ -5368,7 +5378,7 @@ async def _async_get_technology_type_elements(
53685378
"class" : "FilterRequestBody",
53695379
"filter": filter_string,
53705380
"effectiveTime": effective_time,
5371-
"skipClassifiedElements": [skip_templates],
5381+
"skipClassifiedElements": skip_classified_elements,
53725382
"startFrom": start_from,
53735383
"pageSize": page_size,
53745384
**kwargs,

0 commit comments

Comments
 (0)