From baf4c0af5523ce9111441222657fc68526b94cac Mon Sep 17 00:00:00 2001 From: Dan Wolfson Date: Tue, 13 Oct 2026 21:55:10 -0500 Subject: [PATCH] docs(issues): re-derive EGERIA_OPEN_ISSUES.md; retire the 2026-10-05 snapshot EGERIA_OPEN_ISSUES.md was last synced 2026-08-30 (3 entries). It is now re-derived from PYEGERIA_ISSUES.md: 5 open Egeria-side issues in full, 9 awaiting re-test, and the 2 Egeria-side issues tracked as pyegeria items. The snapshot docs/egeria-open-bugs-2026-10-05.md is deleted (it's in git history); its Egeria-team verdicts were already in the log, except for three updates now carried over: - ISSUE-95: addressed on the platform (live) -> awaiting re-test - ISSUE-89: bearerTokenTimeout added in source -> awaiting re-test - ISSUE-85: Egeria added the SolutionPort endpoints -> now a pyegeria gap Signed-off-by: Dan Wolfson --- EGERIA_OPEN_ISSUES.md | 744 ++++++++++------------------ PYEGERIA_ISSUES.md | 231 ++++----- docs/egeria-open-bugs-2026-10-05.md | 236 --------- 3 files changed, 386 insertions(+), 825 deletions(-) delete mode 100644 docs/egeria-open-bugs-2026-10-05.md diff --git a/EGERIA_OPEN_ISSUES.md b/EGERIA_OPEN_ISSUES.md index b333a68b..fb48e468 100644 --- a/EGERIA_OPEN_ISSUES.md +++ b/EGERIA_OPEN_ISSUES.md @@ -1,496 +1,284 @@ # Open Egeria Server Issues -This is a standalone extract of every **currently open, Egeria-Server-side** -issue from [`PYEGERIA_ISSUES.md`](PYEGERIA_ISSUES.md) — nothing here can be -resolved by editing this repo; each needs a server-side fix, an upstream bug -report, or a deployment/config change. It exists to hand to whoever owns the -Egeria server side of a question without making them wade through -`PYEGERIA_ISSUES.md`'s pyegeria-side entries and closed/resolved appendix. - -**`PYEGERIA_ISSUES.md` remains the source of record.** This file is a -generated-by-hand extract of its "Open Egeria Server issues" section as of -2026-08-30 — re-derive it from that section (don't edit the two -independently) whenever an entry here changes status, gets fixed upstream, -or a new server-side issue is filed. - -**Note (2026-09-20):** this extract has not been fully re-derived since -2026-08-30 — `PYEGERIA_ISSUES.md`'s "Open Egeria Server issues" section has -since gained at least ISSUE-102 and a 2026-08-15 Postgres-checkpoint/ -background-connector-load entry that are not reflected below; only -ISSUE-108 was appended here directly (source of record is -`PYEGERIA_ISSUES.md`, this file is due a full re-sync). - -**Down to 2 entries as of the 2026-08-30 refresh** (was 5): ISSUE-52, -ISSUE-54, and ISSUE-41/PY-21 were all confirmed fixed server-side 2026-08-30 -(Egeria team) and moved to `PYEGERIA_ISSUES.md`'s "Fixed / Resolved" -appendix — see that file for the full writeups. ISSUE-38/PY-18 also has a -server-side fix as of the same date but is deliberately kept open here -pending pyegeria-side -verification against real data. +A standalone extract of the **Egeria-Server-side** issues in [`PYEGERIA_ISSUES.md`](PYEGERIA_ISSUES.md), for whoever owns the Egeria side. None of them can be fixed by editing this repo: each needs a server-side fix, an upstream bug report, or a deployment change. + +**`PYEGERIA_ISSUES.md` is the source of record.** This file was **re-derived from it on 2026-10-13** (its "Open Egeria Server issues" and "Awaiting re-test" index lists, plus the Egeria-side entries filed under pyegeria items). Don't edit the two independently. When an entry changes status, change it in `PYEGERIA_ISSUES.md`, then re-derive this file. + +It replaces the 2026-10-05 snapshot `docs/egeria-open-bugs-2026-10-05.md` (deleted; it's in git history). That snapshot's Egeria-team verdicts and fix evidence are now in the individual `PYEGERIA_ISSUES.md` entries. + +## Summary + +| Group | Issues | +|---|---| +| **Open on the Egeria side** (full entries below) | ISSUE-147, ISSUE-143, ISSUE-130, ISSUE-128, ISSUE-108 | +| **Awaiting re-test:** a fix landed (mostly Egeria `main`, odpi/egeria#9363, merged 2026-10-06), not yet verified live | ISSUE-125, ISSUE-124, ISSUE-117, ISSUE-112, ISSUE-95, ISSUE-90, ISSUE-89, ISSUE-79, ISSUE-38 | +| **Egeria-side, but tracked as pyegeria items** (a pyegeria change waits on Egeria) | ISSUE-146, ISSUE-132 | + +## Awaiting re-test + +| Issue | Status (from `PYEGERIA_ISSUES.md`) | +|---|---| +| ISSUE-125: `deleteEnumDef` answers 500 "unknown TypeDef" for an enum the server lists -- an enum added through the API cannot be removed | open; reported to the Egeria team (response 2026-10-05); Egeria fix merged to Egeria `main` 2026-10-06 (odpi/egeria#9363), not yet re-tested on a platform built from it | +| ISSUE-124: `updateTypeDef` (Metadata Expert `open-metadata-types/update`) can never succeed -- the server builds the patch without `updatedBy`, which the repository services require | open; reported to the Egeria team (response 2026-10-05); Egeria fix merged to Egeria `main` 2026-10-06 (odpi/egeria#9363), not yet re-tested on a platform built from it | +| ISSUE-117: Cascade delete that takes the soft-delete (Memento) path fails partway with `OMAG-REPOSITORY-HANDLER-400-010` unless `forLineage=true` — leaves the asset live and an anchored element already soft-deleted | open, workaround known; reported to the Egeria team (response 2026-10-05); Egeria fix merged to Egeria `main` 2026-10-06 (odpi/egeria#9363), not yet re-tested on a platform built from it | +| ISSUE-112: `AutomatedCurationRESTServices.saveClientSideSecret`/`deleteClientSideSecret` return a plain success `VoidResponse` when the resolved connector isn't a `YAMLSecretsFileConnector` — no error, no write, no indication anything was skipped | open | +| ISSUE-95: No catalog template registered for the "Apache Kafka Server" technology type — `Create Kafka Server Element` (Asset Maker) fails with a 400 on `qs-view-server` | awaiting re-test (addressed on the Egeria side, confirmed live 2026-10-05) | +| ISSUE-90: [fixed?] `qs-engine-host` retries `startMissedEngineActions` forever when one incomplete engine action's anchor is unreadable by the engine-host user | open | +| ISSUE-89: No configurable bearer-token lifetime in `application.properties` — platform tokens are fixed at 3600 s, and the signing key is random per restart | awaiting re-test (addressed in Egeria source 2026-09-19; not verified on the dev platform) | +| ISSUE-79: native survey against a template-created `FileFolder` asset fails server-side — `assetConnector` is null in `BasicFolderConnector.getFile()` | open (Egeria Server), reproduced live 2026-08-27, **re-checked | +| ISSUE-38 (PY-18): `count_relationships_between_elements("Exception")` (276) disagrees with `ClassificationExplorer.get_relationships("Exception")` (55) | re-confirmed 2026-08-18, byte-for-byte identical to the | + +## Egeria-side issues tracked as pyegeria items + +- **ISSUE-146: Deleting a journal entry fails with OMAG-REPOSITORY-HANDLER-400-008, and pyegeria's `remove_note` reaches the delete only through the generic Asset Maker service**: Egeria has no note/action delete, and the only route (the asset delete) fails with 400-008 for journal entries; awaiting Egeria's delete fixes. Full entry in `PYEGERIA_ISSUES.md`. +- **ISSUE-132: `DeleteElementRequestBody` serializes the cascade flag as `cascadeDelete`; Egeria's field is `cascadedDelete` and unknown fields are ignored, so no pyegeria cascade delete has ever cascaded**: Egeria's DeleteOptions field is `cascadedDelete`; the pyegeria fix is on hold until Egeria's cascade-delete fix lands. Full entry in `PYEGERIA_ISSUES.md`. + +## Open on the Egeria side + +### ISSUE-147: Every valid-metadata clear call answers OPEN-METADATA-400-011 "not found", even after a successful delete; clear-map-value deletes nothing; clear-map-name leaves the map's value set behind + +**Layer:** Egeria Server (`ValidMetadataValueHandler`) · **Status:** open · **Found:** 2026-10-13. The first live run of the Valid Metadata commands showed it (the error text wasn't captured then). Re-tested the same day with the full responses captured. + +**Re-test:** run once on qs-view-server as erinoverview, with all four live sessions clearing it first. It used made-up properties `pyegeriaClearRetest` and `pyegeriaClearRetestMap` (typeName `Asset`) and called the SDK methods in `pyegeria/omvs/valid_metadata.py`. The Dr.Egeria `Clear Valid Metadata *` commands call the same methods (`md_processing/v2/reference_data.py:198-242`). + +| Call | Response | Actual effect | +|---|---|---| +| `clear_valid_metadata_value(alpha)`, set up just before | 400-011 "value alpha ... is not found" | **alpha removed** (gone from the list afterwards) | +| same call again (alpha already gone) | 400-011 | nothing to remove | +| `clear_valid_metadata_value(beta)` | 400-011 | **beta removed** | +| `clear_valid_metadata_map_value(mapOne, v1)` | 400-011 "value v1 ... is not found" | **nothing removed**: `get_valid_metadata_map_value` still returns v1 | +| `clear_valid_metadata_map_name(mapTwo)` | 400-011 | **mapTwo removed** | +| `clear_valid_metadata_map_name(mapOne)`, with v1 under it | 400-011 | the mapOne name value is removed, but the map's value set "mapOne" (holding v1) stays in `get_valid_metadata_values` | + +Request ids: `ec9052e7` and `3975182d` (alpha), `38759736` (beta), `475e68f1` (map value), `407c0e17` and `07886f29` (map names). pyegeria surfaces each one as `SERVER_ERROR_500` wrapping `relatedHTTPCode` 400 `InvalidParameterException`. + +**Cause (Egeria source, `af400039c2`, `frameworks/open-metadata-framework/.../handlers/ValidMetadataValueHandler.java`):** +1. **No `return` after the delete (lines ~541-680).** In all three `clear*` methods, `if (validValueGUID != null) deleteMetadataElementInStore(...)` is followed unconditionally by the audit log and `throw new InvalidParameterException(VALID_METADATA_MISSING ...)`. So every call throws, whether or not it deleted anything. The "not found" error is the method's normal exit. +2. **Map name dropped in `clearValidMetadataMapValue`.** It calls `getValidValueGUID(userId, typeName, propertyName, null, preferredValue)`, passing `null` where `mapName` belongs. It therefore searches for `v1` as a plain value of the property, finds nothing, and deletes nothing. +3. **`clearValidMetadataMapName` deletes only the name's own value.** It doesn't touch the per-map value set created by `setup-map-value` (the "Set of valid values for the mapOne map name ..." element) or its members. Whether that should cascade is Egeria's call. + +**Effect on Dr.Egeria:** `Clear Valid Metadata Value` and `Clear Valid Metadata Map Name` report failure although the clear worked. `Clear Valid Metadata Map Value` reports failure and really did fail. + +**Leftovers on qs-view-server:** the map value set "mapOne" with member v1 under `pyegeriaClearRetestMap`/`Asset`, plus whatever per-property container elements setup creates (`Egeria:ValidMetadataValue::pyegeriaClearRetest-Asset` and `...pyegeriaClearRetestMap-Asset`). These are test elements, not content-pack elements. RE's blueprint materializer treats `Egeria:ValidMetadataValue:` qualifiedNames as content-pack origin, but only for SolutionComponents, so they don't affect it. + +**pyegeria follow-on (not done, needs the owner's go-ahead):** Dr.Egeria's clear processor could treat 400-011 from `clear-value`/`clear-map-name` as success when a follow-up read confirms the value is gone. Otherwise, wait for the Egeria fix and re-test (see the BACKLOG.md delete re-test item). --- -These need an Egeria Server-side fix, an upstream bug report, or a -deployment/config change — nothing here can be resolved by editing this -repo. Where an entry has a known pyegeria/Dr.Egeria follow-on once the -Egeria side lands, it's noted inline (also cross-referenced from the -"Open pyegeria items" section below where the follow-on is substantial -enough to track there too). +### ISSUE-143: `includeOnlyRelationships: ["PersonRoleAppointment"]` returns no relationships for a Person, although the unfiltered read has its role appointments + +**Layer:** Egeria Server (not pyegeria) · **Status:** open, not yet reported to the Egeria team · **Found:** 2026-10-13, reported by the egeria-workspaces-fs Resource Browser session; reproduced read-only the same day. + +**What:** reading a Person with a `GetRequestBody` whose +`includeOnlyRelationships` is `["PersonRoleAppointment"]` returns the element +with no relationships at all. The same read with no filter returns 8 +`performsRoles` entries, each with relationship type `PersonRoleAppointment`. +Other filters on the same Person work. + +**Reproduction** (Person `10dc7da9-e9e1-471f-9afd-46a7ff414cb7`, Erin Overview, +as erinoverview on qs-view-server; +`ClassificationExplorer.get_element_by_guid(guid, graph_query_depth=1, +output_format="JSON", body={"class": "GetRequestBody", "graphQueryDepth": 1, +"includeOnlyRelationships": [...]})`): + +| Filter | Relationship keys returned | +|---|---| +| none | performsRoles 8, assignmentScope 15, requestedActions 11, contactDetails 1, userIdentities 1, contributionRecord 1 | +| `["ContactThrough"]` | contactDetails 1 | +| `["AssignmentScope"]` | assignmentScope 15 | +| `["PersonRoleAppointment"]` | none | + +A spy on the request confirmed pyegeria sends the body exactly as given, so +the filtering happens in Egeria. + +**Likely cause (not confirmed):** Egeria's relationship filter +(`OpenMetadataHandlerBase`, around line 478) keeps a relationship when +`propertyHelper.isTypeOf(rel, name)`, which should match. But `performsRoles` is +filled in a separate step (`OpenMetadataHandlerBase`, around line 1282), so the +role appointments may be dropped or never fetched once a filter is set. + +**Workaround:** read the Person without `includeOnlyRelationships` and take +`performsRoles` from the result. The Resource Browser already does this. --- -### ISSUE-38 (PY-18): `count_relationships_between_elements("Exception")` (276) disagrees with `ClassificationExplorer.get_relationships("Exception")` (55) - -**Update 2026-08-30, from the Egeria team (Mandy Chessell).** Leaving this -entry in "Open Egeria Server issues" until the verification below has been -run against real data — the Egeria side is done, but this entry has been -re-measured and re-confirmed several times, and it shouldn't move to -Fixed/Resolved on the strength of a change nobody has yet pointed at the -data that produced the original report. - -**Status: resolved on the Egeria side 2026-08-30** (`omf-metadata-spring`, -`omf-metadata-server`, `generic-handlers`, and the OMF Java client) — -**awaiting verification from the pyegeria side**, see below. The two -numbers are not going to be made equal, because they are answers to two -different questions and both are wanted; what has changed is that the -caller now chooses which one they get. - -**What the difference actually was.** `findAttachmentLinks()` puts every -relationship it retrieves through a visibility check on the entities at -both ends, and silently drops the ones whose anchor the caller cannot -read. `countAttachmentLinks()` skipped that check — deliberately, and -documented as such in its own javadoc, because applying it means fetching -every matching relationship, which is the cost the count exists to avoid -— and also ignored `effectiveTime`. So the count was of what matches the -search and the list was of what the caller may see. That answers this -entry's open question ("what does the metadata-expert count include for -`Exception` that the classification-explorer traversal excludes?"): -relationships with an end whose anchor is not readable by the calling -user, plus anything outside the effectivity window. It also explains why -only `Exception` diverged among the types tested — it is the type whose -ends are most likely to have been deleted or anchored to something the -caller cannot see — and why the divergence tracked the demo data rather -than staying at a fixed size. - -**The new option.** Both counting endpoints take a `pushDown` query -parameter, `required=false`, default `true`: -``` -POST .../users/{userId}/relationships/by-search-conditions/count?pushDown=false -POST .../users/{userId}/metadata-elements/by-search-conditions/count?pushDown=false -``` -- `pushDown=true` (the default, and exactly the existing behaviour) — the - repository counts the matching rows itself. Fast, and counts what - matches the search. -- `pushDown=false` — the relationships are retrieved and counted, so the - answer agrees with the list by construction, at the cost of reading - every one of them. - -Nothing changes for a caller that does not send the parameter. The same -choice is on the Java client (`countMetadataElements(..., pushDown)` and -`countRelationshipsBetweenMetadataElements(..., pushDown)` on -`OpenMetadataStore` and `OpenMetadataClient`), with the existing -signatures kept and defaulting to `true`. - -**The test the pyegeria side should run to prove it.** Against the -environment that produced the original numbers, using whatever the -current counts are rather than the 58/57 recorded here — the demo data -has moved several times during this entry's life, and what matters is the -relationship between the numbers, not their values: - -1. **The accurate count should equal the list.** For - `relationshipTypeName: "Exception"`, the count with `pushDown=false` - should equal `len(ClassificationExplorer.get_relationships("Exception"))` - exactly. This is the assertion that closes the entry — it is the - discrepancy this entry is about, stated as an equality. -2. **The fast count should be unchanged.** The same call with - `pushDown=true`, and with the parameter omitted altogether, should both - return what the count returns today. If either moves, something - regressed for every existing caller. -3. **A type that already agreed should still agree both ways.** - `SemanticAssignment` matched at 401=401 when this entry was last - measured. Both `pushDown` values should return that same number — the - retrieval route must not lose or double-count anything on a type where - there was never a discrepancy to resolve. - -Worth capturing while verifying: the difference between the two counts is -the number of matching relationships the calling user cannot fully see. -If it is not the 1 recorded here, that is not a failure — it is a -measurement of the current data — but it is worth writing down, because a -large difference on a type that should be fully visible would be a -separate finding. If test 1 comes out unequal, the remaining difference is -not the visibility check and this entry should stay open with both -numbers recorded. - -**Follow-on for pyegeria, once verified:** the Overview dashboard's -current workaround — keeping relationship counts on -`ClassificationExplorer.get_relationships` while using native counting -only for element counts — can be revisited. -`count_relationships_between_elements(..., pushDown=False)` gives the same -number as the traversal without materialising the list client-side. Keep -in mind that `pushDown=false` reads every matching relationship -server-side, so it is the right choice for a number a user is going to -compare against a list they can also see, and the wrong choice for a -headline figure over a large type where speed is what matters. That -trade-off is now the caller's to make, which is what this entry was -ultimately asking for. - -**Egeria-side test cover:** `CountPushDownFVT` in -`open-metadata-test/open-metadata-fvt/query-fvt` checks that both routes, -over REST and through the Java client, agree when every matching element -is visible, and that omitting the parameter changes nothing. It -deliberately does not attempt the case where they differ — that needs an -element the calling user cannot read, which that suite cannot arrange. -Which is why the verification above, against real data, is the part that -actually proves the fix. - -**Status:** re-confirmed 2026-08-18, byte-for-byte identical to the -2026-08-15 numbers below — `count_relationships_between_elements("Exception")` -still returns 58, `get_relationships("Exception")` still returns 57, same -off-by-one. No change. - -**Status:** re-investigated 2026-08-15, narrowed and re-confirmed -**Egeria server, not pyegeria-fixable** — this is a genuine, real bug, just -smaller than originally measured (demo data has evidently changed since -2026-07-24: `count` is now 58 and `get_relationships` is now 57, not -276/55). Cross-checked against a **second, independent pyegeria list-based -method** — `MetadataExpert.find_relationships_between_elements` (a -different OMVS client, different endpoint, -`.../relationships/by-search-conditions` rather than -`ClassificationExplorer`'s `.../relationships/{type}`) — with the same -`relationshipTypeName: "Exception"` filter: it also returns exactly 57, -and its 57 relationship GUIDs are the **identical set** to -`get_relationships`'s 57 (zero difference either direction). Two -independently-implemented pyegeria code paths through two different -endpoints agree exactly with each other; only the server's native -`COUNT(*)` endpoint (`.../relationships/by-search-conditions/count`) -disagrees, by exactly 1. Also re-confirmed the original "not the type -filter" finding still holds with current data — re-ran `count` vs. -`get_relationships` for `SemanticAssignment` (401=401), `License` (2=2), -`Certification` (0=0), `AttachedRating` (0=0): all match; only `Exception` -diverges. Also checked whether the count includes non-`ACTIVE`/soft-deleted -relationships the list endpoints filter out — no: `limitResultsByStatus: -["ACTIVE"]` and `["ACTIVE","DELETED"]` both still return 58 from `count` -(no status-filter difference). Since both retrieval paths agree with each -other and only the count differs, there's genuinely nothing to fix on the -pyegeria side — this is squarely a server-side discrepancy between the -native COUNT(*) query and the list-materialization logic for this one -relationship type. No further pyegeria action needed; still needs -Egeria-side investigation to say what specifically triggers it for -`Exception`. - -**Original status:** open (Egeria server) — needs Egeria-side investigation. Found -2026-07-24 while wiring the Egeria Overview dashboard to native counting -(odpi/egeria#9168). Consolidated in from `egeria-workspaces-fs/ -PYEGERIA_ISSUES.md` 2026-08-05. - -**Summary:** the OMF metadata-expert native relationship count and the -classification-explorer `get_relationships` return materially different -totals for the `Exception` relationship type — and *only* that type, among -those tested. - -**How to trigger:** -```python -from pyegeria import MetadataExpert, ClassificationExplorer -me = MetadataExpert(view_server="qs-view-server", platform_url="https://localhost:9443", - user_id="erinoverview", user_pwd="secret"); me.create_egeria_bearer_token() -ce = ClassificationExplorer(view_server="qs-view-server", platform_url="https://localhost:9443", - user_id="erinoverview", user_pwd="secret"); ce.create_egeria_bearer_token() - -me.count_relationships_between_elements({"class":"FindRelationshipRequestBody","relationshipTypeName":"Exception"}) -# -> 276 -len(ce.get_relationships(relationship_type="Exception", output_format="JSON", start_from=0, page_size=5000)) -# -> 55 (all 55 have exact typeName "Exception"; no effectivity dates) -``` - -**What it is NOT:** -- Not the type filter — `count("SemanticAssignment")` = 397 = - `get_relationships` = 397; `License` 2 = 2; `Certification` 0 = 0; - `AttachedRating` 0 = 0. Every other tested type matches; only `Exception` - diverges. -- Not status/effectivity — `count("Exception")` is 276 with - `limitResultsByStatus=[ACTIVE]`, with `effectiveTime=`, and with - neither; the 55 `get_relationships` results carry no - `effectiveFromTime`/`effectiveToTime`. -- `count(no relationshipTypeName)` = 31857 (all relationships), so 276 is - a genuine type-scoped subset, not "count ignores the filter". - -**Open question for Egeria:** what does the metadata-expert count include -for `Exception` that the classification-explorer traversal excludes -(subtypes counted under the supertype? relationships to non-visible/ -anchored/dangling ends? access/zone filtering that differs between the two -OMVS)? Whichever is "true", the two APIs should agree for a given type — -or the difference should be documented. - -**Impact / workaround:** egeria-workspaces-fs's Overview dashboard keeps -**relationship** counts on `ClassificationExplorer.get_relationships` (so -"Open Exceptions" stays consistent with the Audit app at 55) and uses -native counting only for **element** counts. +### ISSUE-130: The YAML secrets store's user directory caches a user forever, so editing an existing user needs a platform restart + +**Layer:** Egeria server (`YAMLSecretsStoreConnector`) · **Status:** open, reported to the Egeria lead · **Found:** 2026-10-09, while adding Resource Explorer's own account (`resourceexplorernpa`). + +**What:** `getUser(userId)` returns the entry from `userAccountMap` if it is already there. `refreshSecrets()` re-reads the YAML file every `refreshTimeInterval` minutes, but `userAccountMap` (and `securityAccessControlMap`) are created only on the first load (when `secretsStoreFile == null`) and are never cleared afterwards. Re-reading the file only helps users the cache has never seen; the comment says "this may be a new user". + +**Seen:** the account was first added without its `secrets` block, and the first token request cached it. After the password was added (and matched the servers file), `/api/token` still answered 401 for more than 10 minutes. It worked straight after a platform restart. + +**Effect:** any change to an existing user (password, status, named-list membership) needs a platform restart. + +**Fix (Egeria):** clear or rebuild `userAccountMap` and `securityAccessControlMap` in `refreshSecrets()`. --- -### ISSUE-79: native survey against a template-created `FileFolder` asset fails server-side — `assetConnector` is null in `BasicFolderConnector.getFile()` - -**Update 2026-08-30, from the Egeria team (Mandy Chessell).** The entry -stays in "Open Egeria Server issues" — the reported failure is not -explained and not fixed. What has changed is that the cause recorded in -this entry, and in Resource Explorer's `re-as-engine-host-plan.md`, is now -known to be wrong, and the error it produces has been made legible. - -**Status: still open (Egeria Server)** — but the recorded cause is -disproved, and this entry and `re-as-engine-host-plan.md` should both be -corrected. Investigated 2026-08-30 from the Egeria side, including a new -FVT suite built to run this exact scenario. - -**The premise is false.** This entry, and the design doc's hold, rest on -"template-based asset creation never wires up a working Connection." That -is not true, in either environment it was checked against: - -- **On the quickstart that produced the report.** Every element created - from a template that itself carries a `ResourceConnection` got one — 10 - of 10. Every `FileFolder` in that repository has one, including all - three that were created from a template (`/deployments/content-packs`, - `/deployments/loading-bay/sample-data`, `/deployments/secrets`). -- **In a clean environment built from the current archives.** A folder - catalogued through `FileGovernance::create-file-folder` came back with a - `ResourceConnection` attached. -- **The `FilesContentPack` template itself is also well formed:** - `FileFolder` template `fbdd8efd-...` carries an `Anchors`-classified - `Connection` with both a `ConnectToEndpoint` and a - `ConnectionConnectorType`. - -**The folder survey works.** A new `files-fvt` suite runs the reported -scenario end to end — catalogue a folder from the `FileFolder` template, -then survey it natively — and it passes: -``` -OMES-SURVEY-ACTION-0019 The survey action service folder-survey-service has completed the -analysis of asset 7050dc50-... with request type survey-folder in 1927 milliseconds; the -results are stored in survey report 7e7892e2-... -``` -The report carried six annotations. The test asserts the survey -*completed*, not merely that it ran: a survey that dies on a null -connector still produces an engine action, and the waiter throws on any -terminal status other than `COMPLETED`. - -**A second hypothesis was also eliminated.** While investigating, a real -defect was found in the PostgreSQL repository: a `TypeDefPatch` that -reparents a type does not update the denormalised supertype chain stored -on existing rows, so instances written before the patch become invisible -to searches for the new supertype. That would have hidden connections -exactly as reported, since `AssetConnection` was reparented under -`ResourceConnection` on 2026-08-27. It is fixed — but it was never the -cause here: the quickstart repository stores 202 rows as -`:ResourceConnection:LabeledRelationship:` and none as -`:AssetConnection:`, because it was reloaded after the type change. - -**What has been fixed, and what it does and does not buy.** The NPE -itself is now a clean error. `getConnectorForAsset()` returns `null` by -contract when an asset has no connection; `FolderSurveyService` cast that -null and dereferenced it, and the framework's own -`performCheckAssetAnalysisStep()` had the same hole on its error path. -Both now report `OPEN-SURVEY-400-008` / `OPEN-SURVEY-0009` -(`NO_ASSET_CONNECTOR`), naming the asset. - -This does not make such a survey succeed — an asset with no connection -describes a resource nothing can open. It makes the failure say *which* -asset, which is what the original report was missing: the NPE named -`BasicFolderConnector`, a class the caller had never heard of, and pointed -away from the asset. - -**Why that matters for how this entry reads.** Four further defects were -found in the same connectors, all on paths nothing else exercises: both -file survey services failed on every invocation (annotations created -without a qualified name, in three places), the CSV survey dereferenced a -null root schema type, wrote a relationship property to an entity, and -produced colliding annotation qualified names. The file survey path had, -on this evidence, never run to completion. Someone hitting an NPE in this -family had every reason to suspect the asset — the errors never named -anything else. That is context for the original diagnosis, not a -criticism of it. - -**The naming trap, which is directly actionable on the pyegeria side.** -This entry already records that `initiate_file_folder_survey`'s default -(`FileSurveys:survey-folder`) and the `.http` example -(`AssetSurvey:survey-folder`) are both wrong. Confirmed and now -understood: a governance action type is registered under -`::` — two colons — so the real name is -`FileSurvey::survey-folder`. `AssetSurvey` is not an engine that exists at -all. The `.http` examples have been corrected upstream -(`FileSurvey::survey-folder`, `ApacheKafkaSurvey::survey-kafka-server`, -`PostgreSQLSurvey::survey-postgres-server`, -`PostgreSQLSurvey::survey-postgres-database`) with a note stating the -shape, because the error a wrong name produces — -`OMAG-GENERIC-HANDLERS-400-013`, "the name is not recognized" — does not -say what it wanted instead. `initiate_file_folder_survey`'s default still -needs fixing in pyegeria. - -**What is left, and what would settle it.** The remaining candidate is -the deployment rather than the cataloguing or the survey: which server -and userId the engine host's connected-asset client resolves -`SurveyAssetStore.getConnectorToAsset()` against. That cannot be tested -from the Egeria side — it needs the engine host that produced the -failure. Suggested, in order: - -1. Re-run the original repro against a build carrying the NPE fix. If the - asset genuinely has no connection the run now fails with - `OPEN-SURVEY-400-008` naming it, which turns the question from "why is - this connector null" into "why does this asset have no connection that - this userId can see". If instead the survey completes, the deployment - has moved on and this entry can be closed. -2. Check the folder asset at the moment of failure for a - `ResourceConnection`, using the same userId the engine host runs as — - not an admin one. If the relationship is there but the survey cannot - see it, that is a visibility or server-routing problem, and the userId - is where to look next. -3. Compare against `files-fvt`, which is a known-good baseline for this - exact scenario. Pointing the same two actions at a - differently-configured engine host isolates the variable. - -Also worth correcting: this entry's earlier note about leftover probe -elements (`FileFolder::localhost:/tmp/re-e1-probe-*`, -`FileFolder::localhost:/tmp/re-issue79-recheck-*`) is out of date — the -quickstart repository has been reloaded since and holds none of them, so -that evidence is gone. - -**Status:** open (Egeria Server), reproduced live 2026-08-27, **re-checked -2026-08-28 — still reproduces, identical failure.** Same class/method -(`BasicFolderConnector.getFile()`, `assetConnector` null), same error IDs -(`OMES-SURVEY-ACTION-0018`/`OPEN-SURVEY-500-001`), same -`java.lang.NullPointerException`, against a freshly created `FileFolder` -and a fresh survey run — not a one-off. Filed by content, not by number — -see "why this entry exists" below. - -**Layer:** Egeria Server (survey action framework / `BasicFolderConnector`), -not pyegeria. `create_folder_element_from_template` and the survey-initiate -call both succeed and are correctly formed; the failure happens entirely -inside the server's survey action service. - -**Why this entry exists.** Resource Explorer's `re-as-engine-host-plan.md` -is ON HOLD citing this exact symptom ("connector is null" on a native -survey against a template-created asset) under the name `PYEGERIA_ISSUES.md` -**ISSUE-51** — but this file was renumbered on 2026-08-15, and today's -ISSUE-51 is an unrelated, already-fixed `fetch_element()` shape problem. -The blocker's own content had no surviving entry anywhere in this file. -Investigated fresh rather than guessed at, per the plan's own citation -being untrustworthy. - -**Two candidate bugs were in play, and they are not the same bug:** - -1. **Resource Explorer's superseded tracker, entry E1** (`packages/ - resource-explorer/docs/egeria-pyegeria-issues.md`) describes a *different* - symptom: a 500 from the PostgreSQL repository connector on - `createMetadataElementFromTemplate` (`metadata_collection_guid` null - while saving a classification) — a failure to *create* the element at - all. **Re-tested live 2026-08-27 and does not reproduce**: - `create_folder_element_from_template(path_name=..., folder_name=..., - file_system="localhost")` against `qs-view-server` returned a real GUID - with no error. Whatever this was, it looks fixed. -2. **The design doc's actual blocker** — a template-created asset surveyed - natively fails with a null connector — **does still reproduce**, and is - what this entry tracks. - -**Reproduction** (against `qs-view-server`, no pyegeria bug involved): -```python -from pyegeria import AutomatedCuration -c = AutomatedCuration("qs-view-server", "https://localhost:9443", "erinoverview", "secret") -c.create_egeria_bearer_token() - -folder_guid = c.create_folder_element_from_template( - path_name="/tmp/some-new-path", folder_name="probe-folder", file_system="localhost") - -# Note: initiate_file_folder_survey's own default survey_name -# ("FileSurveys:survey-folder") and the .http ground truth's example -# ("AssetSurvey:survey-folder") are BOTH wrong on this server -- neither -# GovernanceActionType is registered (OMAG-GENERIC-HANDLERS-400-013). The -# real registered qualifiedName, confirmed via -# `EgeriaTech.get_elements("GovernanceActionType")`, is "FileSurvey::survey-folder". -action_guid = c.initiate_file_folder_survey(folder_guid, survey_name="FileSurvey::survey-folder") -``` - -Poll the resulting `EngineAction` (`EgeriaTech.get_elements("EngineAction")`, -match on `elementHeader.guid`) — it completes (fast, ~1s) with -`activityStatus: "FAILED"` and `completionGuards: ["survey-failed"]`. Full -`completionMessage`: -``` -OMES-SURVEY-ACTION-0018 The survey action service folder-survey-service -threw a org.odpi.openmetadata.frameworks.connectors.ffdc.ConnectorCheckedException -exception during the generation of survey report ... for asset - during request type survey-folder in survey action engine -FileSurvey (guid=4168abb9-6c60-46fb-b9c0-b44180d19500). The error message -was OPEN-SURVEY-500-001 Unexpected exception in survey action service -folder-survey-service of type java.lang.NullPointerException detected by -method start. The error message was Cannot invoke -"org.odpi.openmetadata.adapters.connectors.datastore.basicfile.BasicFolderConnector.getFile()" -because "assetConnector" is null -``` - -**Analysis.** `create_folder_element_from_template` creates the `FileFolder` -element and it looks entirely normal (confirmed via `get_elements`: proper -`pathName`, `resourceName`, `Anchors` classification) — but no working -`Connection`/`Connector` got wired to it, so when `folder-survey-service` -tries to open the asset via `BasicFolderConnector.getFile()`, the -connector reference is null and the survey action service crashes with an -NPE rather than a clean error. This matches the design doc's -characterization exactly ("template-based asset creation never wires up a -working Connection, so any native survey against a template-created asset -fails server-side with a NullPointerException") — just with the precise -class/method now on record, which the design doc didn't have. - -**Impact:** blocks Resource Explorer's engine-host participation design -(`re-as-engine-host-plan.md`, cases 1/2/4 — anything needing a native -survey to actually *complete*, not just be triggered; case 3, RE-local -surveying, is unaffected). The hold should be re-evaluated against this -entry specifically, not against the old ISSUE-51 number. As of 2026-08-28 -this is confirmed the *only* thing still blocking that work on the -pyegeria side — ISSUE-78's engine-host method trio shipped in 6.1.5 and RE -has upgraded and verified it end to end, and the two other gaps -identified alongside it (no REST way to create a `GovernanceEngine`/ -`GovernanceService` element; no per-engine "claimable work" listing, -`get_active_engine_actions()` filtered client-side is the only option) are -both genuine server-side gaps, not pyegeria ones. This entry is the real -holdup. - -**Leftover from this investigation:** probe `FileFolder` elements -(`qualifiedName: "FileFolder::localhost:/tmp/re-e1-probe-*"` from -2026-08-27, `"FileFolder::localhost:/tmp/re-issue79-recheck-*"` from the -2026-08-28 re-check) on `qs-metadata-store`, plus their failed -`SurveyReport`/`EngineAction` pairs, left in place as reproduction -evidence for both dates — not yet deleted. +### ISSUE-128: Retention cannot be set on Egeria 6.2: the server registers the Jackson subtype as `RetentionProperties.class` (typo), and pyegeria only allows `RetentionClassificationProperties` + +**Status:** open, found 2026-10-09 by Resource Explorer's first Retention publish on Egeria 6.2. **Layer:** Egeria server (a type registration typo). **Decision (owner, 2026-10-09):** wait for the Egeria fix; no pyegeria workaround. Retention publishing stays blocked until then. + +**What (all proven live on 6.2, with raw HTTP POSTs to `classification-explorer/elements/{guid}/retention` on a throwaway asset):** +- `"class": "RetentionClassificationProperties"` is refused with `InvalidTypeIdException`. This is what pyegeria documents and whitelists, and it worked on the pre-6.2 server (processors.py comment, 2026-08-03). +- `"class": "RetentionProperties"` (the `.http` ground truth) is also refused with `InvalidTypeIdException`. +- `"class": "RetentionProperties.class"` gets **HTTP 200**, and the classification reads back with `retentionBasis` 2 and the notes. +- The server's known-type list in the error has 96 ids. The only Retention entry is literally `RetentionProperties.class`. That looks like an `@JsonSubTypes.Type(name = "RetentionProperties.class")` typo in Egeria's `ClassificationProperties`. +- pyegeria's `validate_new_classification_request` whitelist (`prop=["RetentionClassificationProperties"]`) refuses anything else client-side, so no Retention can be set through pyegeria on 6.2. + +(An earlier version of this entry said 6.2 knows `RetentionProperties`. That was a misread of the error text, corrected the same day.) + +**Where seen:** Resource Explorer's Curate classifications step on two repository assets. Both were refused, so nothing was written. Confidentiality, Criticality, Confidence and Impact property classes are registered normally. + +**Candidate fix:** +1. **Egeria:** correct the subtype name to `RetentionProperties`, matching the `.http` file. Report it to Mandy. +2. **pyegeria, after Egeria's fix:** change the whitelist and docstring to `RetentionProperties`, the `.http` name. No workaround for the typo, by the owner's decision. +3. Re-check `md_processing/v2/processors.py` and `v2/curation.py`, which both pin `RetentionClassificationProperties`. --- ### ISSUE-108: newly created relationships stay invisible to related-element queries for up to ~20 minutes after creation -**Status:** open · **Found:** 2026-09-20, reported by the user from a -Dr.Egeria bulk load session (1,027 expected field-link relationships). +**Layer:** Egeria Server · **Status:** open · **Found:** 2026-09-20, reported by +the user from a Dr.Egeria bulk load session (1,027 expected field-link +relationships). -A catalog walk run immediately after a load found only 876 of 1,027 +**What:** a catalog walk run immediately after a load found only 876 of 1,027 expected field links. A second walk 12 minutes later still showed 82 -structures short. A third walk, 20 minutes after the load, showed every -link present, with no errors raised at any point and no further action -taken in between. See `PYEGERIA_ISSUES.md`'s full entry for the complete -writeup, including why this looks like the same family of symptom as the -2026-08-15 Postgres-checkpoint/background-connector-load entry above -(server falling behind under load, catching up later) rather than a -paging defect like ISSUE-54, and the candidate next step for actually -correlating it with connector/checkpoint activity instead of relying on -these three anecdotal timing checkpoints. - -**Update 2026-09-20:** no upstream `odpi/egeria` issue filed yet, nothing -from the Egeria team. Two independent, unconfirmed peer leads on record in -`PYEGERIA_ISSUES.md`'s full entry: a chronic Kafka consumer-group rebalance -storm on `egeria-shared-kafka` (~90s recurrence, self-heals in seconds — -timescale doesn't obviously match a one-shot ~20min resolution, so -speculative), and a `refreshTimeInterval`-style cache/connector reload -precedent from a different but structurally similar RE investigation. Also -recorded there: a concrete method for telling a fixed-wall-clock cause -apart from a volume-proportional one (smaller timed load + direct-GUID -isolation fetch) before assuming either — not yet run. - -**Update 2026-09-20, small-scale reproduction attempt: not reproduced.** 20 -throwaway `Collection` elements linked via `CollectionMembership` (not the -original `MemberDataField` relationship type) were all visible in a -related-element query within ~1.1s of creation — no lag at current load. -One point on the curve, not a refutation: doesn't distinguish "no bug under -current load" from "genuinely volume-proportional, 20 is far below the -~1,027-link scale that surfaced it." A same-relationship-type, larger-scale -run is the real next step. Full writeup in `PYEGERIA_ISSUES.md`. +structures short. A third walk, 20 minutes after the load, showed every link +present. No errors were raised at any point in the load itself — the +relationships were created successfully, they simply did not show up in +related-element queries for a long window afterward, then all became visible +at once with no further action taken. + +**Not yet root-caused.** This looks like the same family of symptom as the +2026-08-15 Postgres-checkpoint/background-connector-load entry above (server +falling behind under load, catching up later) rather than a paging defect +like ISSUE-54 (which would not self-heal purely by waiting — ISSUE-54's +bug is about tie-ordering across separately-executed pages, not about data +not existing yet). But this has not been directly correlated with connector +log activity or checkpoint timing the way that entry was — this is a fresh +report, not yet independently reproduced or diagnosed by a pyegeria session. + +**Impact:** any workflow that verifies a bulk write immediately after +issuing it (a post-load catalog walk, an integration test, an automated +Dr.Egeria "did it work" check) can get a false-negative "missing" result +that resolves itself given enough time — worth knowing before treating an +immediate post-write verification gap as evidence of a real data-loss bug. + +**Candidate next step (not yet done):** reproduce with a smaller, timed +sample (e.g. create N relationships, poll related-element queries at 1-minute +intervals, log when each becomes visible) to get a real latency +distribution instead of the three anecdotal checkpoints here, and check +whether it correlates with the same background-connector/checkpoint load +already documented above. Worth raising with the Egeria team directly, per +the original report. + +**Update 2026-09-20 (peer check, no upstream issue filed yet):** checked +`odpi/egeria`'s issue tracker directly — nothing filed for this symptom, so +no response from the Egeria team via GitHub. Asked three peer sessions +working against the same dev Egeria server: +- **egeria-workspaces-fs-4a:** hasn't seen this specific symptom, no word + from the Egeria team either. Raised a speculative, explicitly-unconfirmed + lead worth checking: a chronic, still-open issue on `egeria-shared-kafka` + where the `GroupCoordinator` repeatedly times out writing to + `__consumer_offsets` (5000ms) and triggers a consumer-group rebalance + roughly every 90s (confirmed via broker logs 2026-09-03; root cause still + open, CPU/GC/Postgres-restarts/virtiofs I/O already ruled out; historically + "Information" severity, self-heals within seconds, not chased further + since it wasn't visibly causing downstream harm). If `qs-view-server`'s + related-element queries are backed by Kafka-driven indexing/event + propagation rather than a direct repository read, a chronic rebalance + storm could plausibly manifest as exactly this "relationship exists but + isn't visible to queries yet" lag. **Explicitly not a confirmed + correlation** — the timescales don't obviously line up (a recurring ~90s + self-healing blip vs. a one-shot ~20-minute resolution) — and the peer + offered to check Kafka broker logs around the original bulk-load window + for the same rebalance pattern if useful. +- **Resource Explorer experimental UI:** no direct evidence either way — + today's two live writes against the same server (a Governance Action + Process Step upsert, and a native-survey `SurveyReport` lookup) both + checked either *immediately* after the write or only *after* polling to a + terminal status, never in the 1-20 minute gap this entry describes, so + neither confirms nor rules it out. Flagged that a background agent on + their side doing a related connection-refresh fix will trigger fresh + engine actions/relationships shortly and will report back if it surfaces + the same lag. +- **Egeria-trellis backlog review:** also nothing from the Egeria team (no + channel to them; checked RE docs/Backlog/design notes for this exact + shape first — a checked "no", not a guess). Offered a different, measured + precedent on this same platform as a *pattern* to distinguish causes, not + a diagnosis: `packages/resource-explorer/docs/investigation-classification-and-zoning-design.md` + (~line 830) documents a privately-zoned element still readable by a + non-owner *six minutes* after the control was written (denial began at + seven), caused by the security connector's `refreshTimeInterval` (10 min) + reload — "read it back immediately, so it must be fine" was exactly the + misleading evidence there too. Their key diagnostic point: a + **fixed-wall-clock cause** (everything becomes visible at once, at a time + unrelated to load size — test with 50 links instead of 1,027 and see if + the delay is still ~20 min) and a **volume-proportional cause** (async + indexing/event-driven materialisation catching up, arriving in a stream) + look identical from a single observation but have different fixes; the + 876→945(implied)→1,027 partial-recovery-at-12-minutes data point *mildly* + favours volume-proportional, but "two points don't make a curve." Also + worth checking directly: fetch one of the missing links by its own GUID + during the window — if that resolves but the relationship is still absent + from the related-element query, the write landed fine and only the + traversal/index path lags, narrowing which service is actually behind. If + this gets filed upstream, the volume-vs-fixed measurement is what turns + it into a real bug report instead of getting bounced as "eventual + consistency, working as intended." + +Two independent, unconfirmed leads now on record (Kafka rebalance storms; +a refresh-interval-style cache) alongside a concrete diagnostic method +(fixed-wall-clock vs. volume-proportional, plus the direct-GUID-fetch +isolation check) for telling them apart before assuming either. Next real +step is still reproducing with a smaller, timed, instrumented load using +that method — not yet done. + +**Reproduction attempt, 2026-09-20 (small end of the curve, not reproduced):** +after clearing with all 5 live peer sessions first (per `coordinate-shared-writes`), +ran a timed, instrumented small-scale reproduction against `qs-view-server`: +20 throwaway `Collection` elements created and each linked to a parent via +`CollectionMembership` (not the original `MemberDataField`/"field link" type +— a different relationship type, noted as a limitation below), polling +`get_collection_members` every 30s for up to 20 minutes, with a direct-GUID +isolation check ready for anything still missing at the deadline. + +**Result: all 20 relationships were visible on the very first poll, ~1.1s +after the last one was created — no lag at all.** Cleanup (delete all 21 +fixture elements) verified two independent ways: a direct-GUID fetch on +each (`404`/`OMAG-REPOSITORY-HANDLER-404-007`, confirmed real soft-delete, +not an ISSUE-63-style silent no-op) and a broad `find_collections` search +for the `test-fixture-issue108` prefix (0 results). The script itself was +run from an ephemeral per-session scratch directory, not committed anywhere +— reproduce via the same approach (create N Collections linked to a parent +via `_async_add_to_collection`, poll `_async_get_collection_members`) if +needed later; the approach, not the script file, is what's worth keeping. + +**Per Egeria-trellis backlog review's own framework, this is one point on +the curve, not a refutation.** It's consistent with either "no bug under +current load" or "the lag is genuinely volume-proportional and 20 elements +is nowhere near the ~1,027-link scale that surfaced it originally" — the +one data point this run *can't* distinguish those two. Also a real +methodology gap versus the original report: this used `CollectionMembership` +on plain `Collection` elements, not the `MemberDataField` "field link" +relationship the original 1,027-link load actually exercised (ISSUE-102 is +in the same `MemberDataField` neighborhood, worth checking together). Server +load conditions also weren't recorded this run (no `ListAgents`/`:8810` +snapshot taken alongside the timings, despite the earlier plan to do so — +an execution gap, not a design one). + +**Candidate next step, still open:** a same-relationship-type +(`MemberDataField`), same-order-of-magnitude (~200+) run, following the +same peer-clearance and independent-verification discipline, is what would +actually test the volume-proportional hypothesis — this run didn't attempt +that scale on its own initiative, since committing to it wasn't part of +what peers were asked to clear. + +**Egeria team response, relayed 2026-10-05 (source `oak2026` fb3d6fce53; **fixes are in two unmerged PRs, so no build contains them, and nothing was tested against a live platform**):** not validated; no cache found. Best lead: a client clock ahead of the server's, with `effectiveFrom` set from it (related-element queries silently hide a relationship whose `effectiveFrom` is later than the server's "now"). They need, for one link still missing at ~12 minutes: its `effectiveFrom` and `createTime`, the server clock then, and whether the loader sets `effectiveFrom`. **Our facts:** pyegeria sets no `effectiveFrom`/`effectiveTo`/`effectiveTime` by default (model defaults are `None`; no clock call is tied to any `effective*` field; Dr.Egeria forwards an "Effective From" only if typed). Host and container clocks agree within 1 s on 2026-10-05; the 2026-09-20 load's values are unavailable. + +**Update 2026-10-10:** the `oak2026` source (`fb3d6fce53`) the team examined is now in Egeria `main` (merged 2026-10-06, odpi/egeria#9363). No fix was made for this issue; the team's questions above still stand. + +--- diff --git a/PYEGERIA_ISSUES.md b/PYEGERIA_ISSUES.md index 53be9415..12411911 100644 --- a/PYEGERIA_ISSUES.md +++ b/PYEGERIA_ISSUES.md @@ -155,13 +155,16 @@ content was changed. The numbered section list above describes the - ISSUE-146: Deleting a journal entry fails with OMAG-REPOSITORY-HANDLER-400-008, and pyegeria's `remove_note` reaches the delete only through the generic Asset Maker service - ISSUE-132: `DeleteElementRequestBody` serializes the cascade flag as `cascadeDelete`; Egeria's field is `cascadedDelete` and unknown fields are ignored, so no pyegeria cascade delete has ever cascaded - ISSUE-127: `CollectionManager.delete_collection(cascade=True)` silently never sends `cascadeDelete` -- same shape as ISSUE-62 +- ISSUE-85: No REST endpoint exists to create a `SolutionPort` element — only attach/detach/delegation relationships are exposed **Awaiting re-test** - ISSUE-125: `deleteEnumDef` answers 500 "unknown TypeDef" for an enum the server lists -- an enum added through the API cannot be removed - ISSUE-124: `updateTypeDef` (Metadata Expert `open-metadata-types/update`) can never succeed -- the server builds the patch without `updatedBy`, which the repository services require - ISSUE-117: Cascade delete that takes the soft-delete (Memento) path fails partway with `OMAG-REPOSITORY-HANDLER-400-010` unless `forLineage=true` — leaves the asset live and an anchored element already soft-deleted - ISSUE-112: `AutomatedCurationRESTServices.saveClientSideSecret`/`deleteClientSideSecret` return a plain success `VoidResponse` when the resolved connector isn't a `YAMLSecretsFileConnector` — no error, no write, no indication anything was skipped +- ISSUE-95: No catalog template registered for the "Apache Kafka Server" technology type — `Create Kafka Server Element` (Asset Maker) fails with a 400 on `qs-view-server` - ISSUE-90: [fixed?] `qs-engine-host` retries `startMissedEngineActions` forever when one incomplete engine action's anchor is unreadable by the engine-host user +- ISSUE-89: No configurable bearer-token lifetime in `application.properties` — platform tokens are fixed at 3600 s, and the signing key is random per restart - ISSUE-79: native survey against a template-created `FileFolder` asset fails server-side — `assetConnector` is null in `BasicFolderConnector.getFile()` - ISSUE-38 (PY-18): `count_relationships_between_elements("Exception")` (276) disagrees with `ClassificationExplorer.get_relationships("Exception")` (55) @@ -171,9 +174,6 @@ content was changed. The numbered section list above describes the - ISSUE-130: The YAML secrets store's user directory caches a user forever, so editing an existing user needs a platform restart - ISSUE-128: Retention cannot be set on Egeria 6.2: the server registers the Jackson subtype as `RetentionProperties.class` (typo), and pyegeria only allows `RetentionClassificationProperties` - ISSUE-108: newly created relationships stay invisible to related-element queries for up to ~20 minutes after creation -- ISSUE-95: No catalog template registered for the "Apache Kafka Server" technology type — `Create Kafka Server Element` (Asset Maker) fails with a 400 on `qs-view-server` -- ISSUE-89: No configurable bearer-token lifetime in `application.properties` — platform tokens are fixed at 3600 s, and the signing key is random per restart -- ISSUE-85: No REST endpoint exists to create a `SolutionPort` element — only attach/detach/delegation relationships are exposed --- @@ -186,6 +186,74 @@ into the entry now, so it isn't rediscovered from scratch later. --- +### ISSUE-85: No REST endpoint exists to create a `SolutionPort` element — only attach/detach/delegation relationships are exposed + +**Status:** open, now a pyegeria gap (Egeria added the endpoints 2026-09-06) +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. + + +**Egeria side addressed (2026-10-05 check, carried over from the retired `docs/egeria-open-bugs-2026-10-05.md`):** at `449ad06894`, Solution Architect has `createSolutionPort` and `createSolutionPortFromTemplate`, with endpoints `POST /solution-ports`, `/solution-ports/from-template`, `/solution-ports/{guid}/update`, `.../delete`, `/by-name`, `/by-search-string` and `.../retrieve`. They first appear in commit `571034df11` (2026-09-06). The running platform answers `POST /solution-ports/by-name` with 200. **Remaining (pyegeria):** the `.http` snapshot lists none of these, and `pyegeria/omvs/solution_architect.py` has no `create_solution_port` (or update, delete, find). Add them, ideally with Dr.Egeria support. +--- + ### ISSUE-150: Dr.Egeria commands for an Analytic Function's Egeria declaration: a GovernanceActionType that Resource Explorer runs as an engine host, plus a synchronous path that bypasses Egeria @@ -1438,116 +1506,8 @@ what peers were asked to clear. --- -### ISSUE-95: No catalog template registered for the "Apache Kafka Server" technology type — `Create Kafka Server Element` (Asset Maker) fails with a 400 on `qs-view-server` - -**Layer:** Egeria Server (deployment/archive content) · **Status:** open, being investigated by the user (2026-09-11) · **Found:** 2026-09-11, live-verifying the new Asset Maker Dr.Egeria family (#354) - -`AutomatedCuration._async_get_template_guid_for_technology_type("Apache Kafka Server")` -returns `None` on `qs-view-server` — no catalog template is registered for -that technology type on this server — so `Create Kafka Server Element`'s -underlying `_async_create_kafka_server_element_from_template` posts a body -with `templateGUID: null` and gets back `VALIDATION_ERROR_1` ("Request body -failed validation"). Not a pyegeria code defect: every other Asset Maker -technology type tried resolved a real template GUID on the same server -(CSV Data File, PostgreSQL Server, File System Directory, YAML File Secrets -Collection, Unity Catalog Server) — this one is specific to the Kafka -technology type's archive content on this deployment. `Create Kafka Server -Element` itself is otherwise correct (parses/validates cleanly; the failure -is entirely server-side at execution). - -**Ask:** confirm whether the Apache Kafka Server catalog template is -expected to ship with quickstart's default archive content, and if so, why -it's missing here — or add it to whichever archive/content-pack is meant to -carry it. - ---- - -### ISSUE-89: No configurable bearer-token lifetime in `application.properties` — platform tokens are fixed at 3600 s, and the signing key is random per restart - -**Layer:** Egeria Server · **Status:** open · **Found:** 2026-09-04 (trellis-auth token contract) - -With `authentication.mode=token`, every token minted by the platform decodes to `exp - iat = 3600` -(observed on `omag-server-platform-6.2-SNAPSHOT`, quickstart, `authentication.source=platform`). -`application.properties` exposes `authentication.mode`, `authentication.source` and `rsa.key-id`, and -nothing that controls the lifetime; with `rsa.key-id` empty the signing key is regenerated at start, so -every token also dies on a platform restart. Client applications that hold a platform token on the -user's behalf (Portal, Egeria Advisor, Resource Explorer — which now carry the Egeria bearer token in -their session and never the password) cannot offer a session longer than an hour without either -re-prompting the user or caching a password, which is what a bearer token exists to avoid. - -**Ask:** a property such as `authentication.token.lifetime=3600` (seconds, default unchanged), read at -start and applied when a token is issued; optionally a refresh operation that returns a new token for a -valid unexpired one. Full draft issue text: trellis session scratch `egeria-issue-token-lifetime.md`. - -**Correction, 2026-10-05 (Egeria team; confirmed in `RSAGenerator`):** the statement above that an empty `rsa.key-id` is why the signing key is regenerated is wrong. `RSAGenerator.generateRSAKeyPair(keyId)` always makes a fresh key pair and only uses the id as a label, so **no setting makes tokens survive a restart**; persisting the key is planned for the next release. Also: the lifetime property now exists, `bearerTokenTimeout` in HOURS (default 1), added in `a1f228d4a9` (2026-09-19); there is still no refresh operation. - ---- - -### 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. - ---- # Quick reference: which OMVS client class for which purpose @@ -2527,6 +2487,55 @@ Also added to the Quick reference table. Test: --- +### ISSUE-95: No catalog template registered for the "Apache Kafka Server" technology type — `Create Kafka Server Element` (Asset Maker) fails with a 400 on `qs-view-server` + +**Layer:** Egeria Server (deployment/archive content) · **Status:** awaiting re-test (addressed on the Egeria side, confirmed live 2026-10-05) · **Found:** 2026-09-11, live-verifying the new Asset Maker Dr.Egeria family (#354) + +`AutomatedCuration._async_get_template_guid_for_technology_type("Apache Kafka Server")` +returns `None` on `qs-view-server` — no catalog template is registered for +that technology type on this server — so `Create Kafka Server Element`'s +underlying `_async_create_kafka_server_element_from_template` posts a body +with `templateGUID: null` and gets back `VALIDATION_ERROR_1` ("Request body +failed validation"). Not a pyegeria code defect: every other Asset Maker +technology type tried resolved a real template GUID on the same server +(CSV Data File, PostgreSQL Server, File System Directory, YAML File Secrets +Collection, Unity Catalog Server) — this one is specific to the Kafka +technology type's archive content on this deployment. `Create Kafka Server +Element` itself is otherwise correct (parses/validates cleanly; the failure +is entirely server-side at execution). + +**Ask:** confirm whether the Apache Kafka Server catalog template is +expected to ship with quickstart's default archive content, and if so, why +it's missing here — or add it to whichever archive/content-pack is meant to +carry it. + + +**Addressed on the Egeria side (2026-10-05 check, carried over from the retired `docs/egeria-open-bugs-2026-10-05.md`):** the running platform resolves a template. `get_template_guid_for_technology_type("Apache Kafka Server")` returns `5e1ff810-5418-43f7-b7c4-e6e062f9aff7`, and Egeria source `449ad06894` ships `ApacheKafkaContentPack.omarchive`. It looks like a content-pack loading matter, not a code defect. **Remaining:** re-test `Create Kafka Server Element` live. +--- + +### ISSUE-89: No configurable bearer-token lifetime in `application.properties` — platform tokens are fixed at 3600 s, and the signing key is random per restart + +**Layer:** Egeria Server · **Status:** awaiting re-test (addressed in Egeria source 2026-09-19; not verified on the dev platform) · **Found:** 2026-09-04 (trellis-auth token contract) + +With `authentication.mode=token`, every token minted by the platform decodes to `exp - iat = 3600` +(observed on `omag-server-platform-6.2-SNAPSHOT`, quickstart, `authentication.source=platform`). +`application.properties` exposes `authentication.mode`, `authentication.source` and `rsa.key-id`, and +nothing that controls the lifetime; with `rsa.key-id` empty the signing key is regenerated at start, so +every token also dies on a platform restart. Client applications that hold a platform token on the +user's behalf (Portal, Egeria Advisor, Resource Explorer — which now carry the Egeria bearer token in +their session and never the password) cannot offer a session longer than an hour without either +re-prompting the user or caching a password, which is what a bearer token exists to avoid. + +**Ask:** a property such as `authentication.token.lifetime=3600` (seconds, default unchanged), read at +start and applied when a token is issued; optionally a refresh operation that returns a new token for a +valid unexpired one. Full draft issue text: trellis session scratch `egeria-issue-token-lifetime.md`. + +**Correction, 2026-10-05 (Egeria team; confirmed in `RSAGenerator`):** the statement above that an empty `rsa.key-id` is why the signing key is regenerated is wrong. `RSAGenerator.generateRSAKeyPair(keyId)` always makes a fresh key pair and only uses the id as a label, so **no setting makes tokens survive a restart**; persisting the key is planned for the next release. Also: the lifetime property now exists, `bearerTokenTimeout` in HOURS (default 1), added in `a1f228d4a9` (2026-09-19); there is still no refresh operation. + + +**Addressed in Egeria source (2026-10-05 check, carried over from the retired `docs/egeria-open-bugs-2026-10-05.md`):** commit `a1f228d4a9` (2026-09-19, "Add control of bearer token timeout") added `bearerTokenTimeout`, read by `TokenService`, in **hours** (default 1; the request asked for seconds). It is in `application.properties` and `container.application.properties`. **Not covered:** a token refresh operation. The signing key also changes on every restart: `rsa.key-id` does **not** prevent that (confirmed in `RSAGenerator.generateRSAKeyPair`: it always makes a fresh key pair and uses the id only as a label), and the Egeria team plans to persist the signing key in the next release. **Remaining:** verify on a platform built after 2026-09-19. +--- + ### ISSUE-113: `NewElementRequestBody` has no `initial_status` field, so `initialStatus` is silently dropped on every create routed through it **Layer:** pyegeria · **Status:** fixed 2026-10-12 on branch `docs/issue-136` (PR pending), not yet released; reclassified: not a missing model field · **Found:** 2026-09-21, verifying diff --git a/docs/egeria-open-bugs-2026-10-05.md b/docs/egeria-open-bugs-2026-10-05.md deleted file mode 100644 index 130c5d68..00000000 --- a/docs/egeria-open-bugs-2026-10-05.md +++ /dev/null @@ -1,236 +0,0 @@ -# Open Egeria server bugs: validated, ranked, with fix status - -**Compiled:** 2026-10-05, from `PYEGERIA_ISSUES.md` (the pyegeria issues log), then checked against Egeria's source and the running dev platform. -**Scope:** Egeria-side defects and gaps only. pyegeria-side issues (121, 126, 127, ...) and everything already resolved are excluded. - -## Baseline (read this first) - -| | | -|---|---| -| **Source analysed** | `odpi/egeria` `main` at **`449ad06894`** (2026-10-05 14:12 UTC, "Merge pull request #9357 from mandy-chessell/oak2026"), pulled into `~/localGit/egeria-v5-1/egeria-aug-5-24` | -| **Platform observed** | the running quickstart platform, image `egeria-quickstart-platform:local` **built 2026-10-03 ~18:46 UTC**, last (re)started 2026-10-05 01:43 UTC | -| **Redeploy** | **done 2026-10-05.** The platform image was rebuilt at 14:19 UTC (after the 14:12 UTC source tip) and `egeria-main` restarted at 14:39 UTC. Items marked "live" below were observed on the **2026-10-03** build unless they say "after redeploy". | - -**Update, 2026-10-05, after the redeploy** (platform rebuilt from the pulled source: image created 14:19 UTC, `egeria-main` restarted 14:39 UTC, healthy). Four live checks have now been run on that build: - -| Issue | Result on the rebuilt platform | -|---|---| -| **ISSUE-125** (`deleteEnumDef`) | **still fails**, identically; the enum also survived the restart | -| **ISSUE-124** (`updateTypeDef`) | **still fails**, with the same `updatedBy` error | -| **ISSUE-102** (`MemberDataField` min/max) | **no longer reproduces**: four min/max pairs all stored correctly. **This corrects my source-based call of "not addressed"** (see "How to read this") | -| **ISSUE-90** (engine-host retry loop) | **not reproduced, but the trigger was absent**, so it is *not shown fixed*: no refusals and calm CPU, yet no `APPROVED` engine action exists for the loop to retry | - -**ISSUE-79** (folder from template, run 2026-10-06 with current pyegeria): the new folder **has a `ResourceConnection`**, so the old `deepCopy:false` default was the cause of the missing connection; the survey itself was not run, so "survey completes" is still unproven (section 5). - -The remaining re-tests (112, 117, 85 create, 89, 95 create, 108) have not been run yet. - -**Earlier update, 2026-10-05 afternoon:** after pulling the source, every "not addressed" finding was re-checked against `449ad06894` itself. **No status changed.** The result for each is repeated under "Re-check at `449ad06894`" below. The next step is to redeploy and re-test live (plan at the end), because a fix present in source says nothing about the build that is running. - -## Egeria team response (relayed 2026-10-05 evening) - -The Egeria team answered this list (via the owner and the Resource Explorer coordinator), from source `oak2026` `fb3d6fce53` (main through #9358). **Read their hedges first:** every fix below is in source on the `oak2026` branch in **two PRs that are not merged to `main`, so no build contains them**. They traced code and, for ISSUE-102, ran a scratch program; they **tested nothing against a live platform** and will confirm when the fixes merge. - -| Issue | Egeria team verdict | Our check (2026-10-05) | -|---|---|---| -| 102 | **Not reproduced** in Egeria; builder and converter round trip returns `position=3, min=1, max=5`; lower layers not traced. They want the raw request, raw response and read-back endpoint | Agrees: it also **no longer reproduces** on our rebuilt platform. The original raw response was never captured | -| 90 | **Valid, fixed pending merge**: one unreadable action target throws, the outer `catch` ends the sweep, newest-first paging brings the bad page back; the sweep is also unfiltered by engine | Agrees with our source reading; the engine-scoped sweep is new to us | -| 112 | **Valid, fixed pending merge**: a store whose connector cannot write now answers 400 `OMAG-COMMON-400-034` | Agrees | -| 124 | **Valid, fixed pending merge**; `updateTime` was missing as well as `updatedBy` | Our `updatedBy` analysis was right but **incomplete** | -| 117 | **Valid, fixed pending merge**: the `qualifiedName` rename happens *after* the Memento classification; the top-level asset is also never renamed | Agrees with the symptom; the cause is sharper than our inference | -| 125 | **Valid, fixed pending merge**; cause is **not** a GUID-map problem: `OMRSRepositoryContentValidator:877` passes `(guidParameterName, guid)` to an overload expecting `(guid, name)`, so every `deleteAttributeTypeDef` fails | **Confirmed in source; our GUID-map theory was wrong** | -| 79 | **Very likely fixed** by `e01426db86` (2026-08-30); also: *check pyegeria does not send `deepCopy:false`* | **Probably our bug**: pyegeria sent `deepCopy:false` by default until 2026-09-29 (see section 5) | -| 89 | `bearerTokenTimeout` in hours, default 1; **correction: `rsa.key-id` does not make tokens survive a restart** | **Confirmed in `RSAGenerator`**; our earlier statement was wrong | -| 95, 85 | Confirmed (content pack present; server endpoints exist) | Agrees; the pyegeria `SolutionPort` methods are still missing | -| 108 | **Not validated**; best lead: a client clock ahead of the server's, with `effectiveFrom` set from it | pyegeria sets **no** `effectiveFrom` by default; clocks agree within 1 s now; the Sept 20 load cannot be inspected | - -The stray enum `PyegeriaTmpCuisineType` (`118441be-6e03-4442-96c6-e431f75fcb3f`) can only be deleted after a build with the ISSUE-125 fix is deployed. - -## How to read this - -- **Ranking** is by (1) silent wrong data, (2) whole-platform impact, (3) a feature blocked outright, (4) workflow friction or missing capability. Within a tier, deterministic beats intermittent. -- **Validated** means the log records a live reproduction or a confirmation against Egeria's source. Ten are validated; a further one (ISSUE-108) is a single report that has not been reproduced and is listed separately. -- **Fix status** compares the source at `449ad06894` (2026-10-05) with the checkout as it stood on 2026-09-15 (`df82f4feca`, 70 commits earlier), by file, by commit message and by reading the code. -- **Caveat that matters:** "fixed in source" is not "fixed on the dev platform", and the reverse also holds. Items marked *live* were tested against a running server; the build is named where it matters. -- **Lesson from ISSUE-102:** comparing source files said "not addressed" (no commits to the bean, converter or builder), yet the live re-test shows the bug gone. A source comparison can miss a fix in a file I did not inspect, or the build that originally reproduced the bug may simply have been older than my baseline. **Treat every "not addressed" below that rests on source alone as provisional until it is live-tested.** The live-tested ones (124, 125) are firm. - -## Summary - -| Rank | Issue | Defect | Fix status | -|---|---|---|---| -| 1 | **ISSUE-90** | `qs-engine-host` retries a failing `startMissedEngineActions` forever; platform and Postgres CPU saturated | **Valid; fix in Egeria source, pending merge** (no build has it). Live after redeploy: not reproduced, but the trigger was absent | -| 2 | **ISSUE-112** | `saveClientSideSecret` / `deleteClientSideSecret` report success without writing when the connector is not a `YAMLSecretsFileConnector` | **Valid; fix in Egeria source, pending merge** (no build has it); not live-tested | -| 3 | **ISSUE-124** | `updateTypeDef` can never succeed: the patch is built without the mandatory `updatedBy` | **Valid; fix in Egeria source, pending merge**; **re-tested live after the redeploy: still fails** | -| 4 | **ISSUE-117** | Cascade delete on the soft-delete path fails partway, leaving a half-deleted state | **Valid; fix in Egeria source, pending merge** (no build has it); not live-tested | -| 5 | **ISSUE-79** | Native survey of a template-created `FileFolder` fails: `assetConnector` is null in `BasicFolderConnector.getFile()` | **Probably a pyegeria bug** (`deepCopy:false` default until 2026-09-29); Egeria also repaired a related server issue; needs a live re-test | -| 6 | **ISSUE-125** | `deleteEnumDef` answers 500 "unknown TypeDef" for an enum the server lists | **Valid; fix in Egeria source, pending merge**; cause corrected (argument order, not a GUID map); **re-tested live: still fails** | -| 7 | **ISSUE-95** | No catalog template for "Apache Kafka Server" | **Addressed**, confirmed by live probe | -| 8 | **ISSUE-85** | No REST endpoint to create a `SolutionPort` | **Addressed** in source, confirmed by live probe | -| 9 | **ISSUE-89** | No configurable bearer-token lifetime | **Addressed** in source (2026-09-19) | -| 10 | **ISSUE-102** | `MemberDataField.minCardinality` silently stored as `maxCardinality`'s value (was rank 1) | **No longer reproduces** on the rebuilt platform (live, four cases); the Egeria team could not reproduce it either | -| n/a | ISSUE-108 | Relationships invisible to queries for up to ~20 min after creation | **Not validated**, cannot assess | - -**Status with the Egeria team:** 90, 112, 117, 124 and 125 are acknowledged as valid with fixes in source (`oak2026`), pending merge and then a deployed build; 102 and 108 could not be reproduced by them; 79 is probably on our side; 95, 85 and 89 are settled. - ---- - -## Open and validated - -### 1. ISSUE-90: engine host retries `startMissedEngineActions` forever - -- **Evidence:** observed on one quickstart: the same refusal, `OMAG-SERVER-SECURITY-403-007 User generalnpa is not authorized to issue operation Read on anchor element DigitalProductFamily`, thousands of times; the platform container at 200-330% CPU and its Postgres at 500-750% on an idle machine. A second, identical platform never showed it, so it depends on initialisation history. The log entry's title carries "[fixed?]", which is unconfirmed. -- **Impact:** platform-wide slowdown while it lasts. It is intermittent, which lowers its rank despite the severity. -- **Fix status: not addressed.** `GovernanceEngineHandler.startMissedEngineActions` wraps the paged fetch in one outer `try`/`catch`: an exception from `getActiveEngineActions` aborts the whole pass at that page, and the next scheduled pass fails at the same page again. The only change between 2026-09-15 and now is in the per-action `catch`, where `logException` became `logMessage` (less log volume), which does not touch the loop. -- **Suggested upstream change (from the log):** treat an authorization failure for a specific engine action as terminal for that action (log once, skip, continue), and/or give `generalnpa` read access to the elements its engine actions anchor to. -- **Re-tested after the redeploy (2026-10-05, read-only, 32 minutes after the 14:39 UTC restart):** - - **Not reproduced.** Zero `ENGINE-HOST-SERVICES-2002`, `startMissedEngineActions` or `OMAG-SERVER-SECURITY-403-007` in the platform log; the engine host refreshes its engines normally. The platform container is at about 50% of one core and Postgres at about 30%, against 200-330% and 500-750% originally. - - **The trigger was absent, so this proves little.** Only two engine actions are active, a `REQUESTED` PostgreSQL survey and the `IN_PROGRESS` watchdog, and `startMissedEngineActions` only processes `APPROVED` ones. A clean run cannot tell "fixed" from "not triggered", exactly as the original report warned. - - **Unreadable anchors do exist.** 381 `OPEN-METADATA-SECURITY-0011` read refusals, all for `erinoverview` (my scripts' account), across 11 elements anchored to a `DigitalProduct` (6) or `DigitalProductFamily` (5), in bursts of 20 that match page-sized searches, not a steady loop. None were for the engine-host user `generalnpa`, and the original element (`a0baa4da-...`) is not among them. So quickstart content does carry elements an ordinary user cannot read, which is the precondition the report hypothesised. Whether an engine action anchors to one is not shown. - - **Verdict: still open, latent.** The outer `catch` in source is unchanged, so an `APPROVED` action with an unreadable anchor would still loop. -- **Egeria team response (2026-10-05):** valid; fix in source on `oak2026`, pending merge. Cause: `startMissedEngineActions` runs every 5 s per engine; `getActiveEngineActions` reads every action target and requester, so one target anchored to an element the engine's user cannot read (zone) throws, the outer `catch` ends the sweep, and newest-first paging brings the bad page back. The sweep is also unfiltered by engine (every engine pages all active actions every 5 s), a likely contributor to the idle CPU (unmeasured). Fixes: unreadable actions filtered out, one-time error logging, anchor message arguments in the right order, an engine-scoped sweep via a new `.../governance-engines/{guid}/approved-engine-actions` endpoint, and anchor-refused search results filtered instead of logged as unauthorized. The last point may also explain the very high rate of read refusals seen on the platform. - -### 2. ISSUE-112: secrets calls report success without writing - -- **Evidence:** confirmed in source and live. `AutomatedCurationRESTServices.saveClientSideSecret` and `deleteClientSideSecret` only act `if (connector instanceof YAMLSecretsFileConnector)`; there is no `else`, no error and no log, so any other connector resolves to a plain success `VoidResponse`. -- **Impact:** a secret is not saved while the call says it was. No workaround is recorded; a caller would have to read back to know. -- **Fix status: not addressed.** `AutomatedCurationRESTServices.java` has no commits since 2026-09-15, and the `instanceof` block at line 480 still has no `else` branch. -- **Egeria team response (2026-10-05):** valid; fix in source on `oak2026`, pending merge. A store whose connector cannot write secrets collections now gets a 400 `OMAG-COMMON-400-034` naming the operation, asset and connector class. Only `YAMLSecretsFileConnector` supports save and delete (`SecretsStoreConnector` gained `isSecretsCollectionUpdateSupported()`, and the others reject with `OCF-CONNECTOR-400-012`). Also fixes a `methodName` slip and always disconnects the connector. - -### 3. ISSUE-124: `updateTypeDef` can never succeed - -- **Evidence:** live and from source, 2026-10-05. A valid `OpenMetadataTypeDefPatch` is rejected with `OMRS-REPOSITORY-400-069 ... mandatory field updatedBy set to null`. The request arrived intact: its attribute definition is visible in the error text. -- **Cause:** `OpenMetadataStoreRESTServices.updateTypeDef` calls `converter.getTypeDefPatch(requestBody, methodName)`. `OMRSTypeDefConverter.getTypeDefPatch` takes no user id and contains no `setUpdatedBy`, yet `OMRSMetadataCollection.updateTypeDef` requires `updatedBy` to be non-null. `OpenMetadataTypeDefPatch` has no `updatedBy` field, so a client cannot supply it. -- **Impact:** the feature is blocked outright, with no client workaround. The upstream fix is small: pass `userId` to the converter and set it. -- **Fix status: not addressed.** The dynamic type APIs arrived in commit `a33921ffd9` (2026-09-24). Nothing since has touched this path. The one `setUpdatedBy` in `OpenMetadataStoreRESTServices.java` is in the *response* conversion, not the patch. -- **Re-tested after the redeploy (2026-10-05, build of 14:19 UTC):** a throwaway entity type (primitive attribute only) was added, then patched with one new attribute. The server rejected the patch with the **same** `OMRS-REPOSITORY-400-069 ... mandatory field updatedBy set to null` (`TypeDefPatch{... applyToVersion=1, updateToVersion=2, newVersionName=2.0, updatedBy=null ...}`). The type was deleted afterwards and verified gone. **Confirmed still present.** -- **Upstream:** not yet reported. -- **Egeria team response (2026-10-05):** valid, and `updateTime` was missing as well as `updatedBy` (so our analysis was right but incomplete). Fix in source on `oak2026`, pending merge: `getTypeDefPatch` takes the user and sets both, with a new `DynamicTypeFVT`. No build contains it. - -### 4. ISSUE-117: cascade delete fails partway on the soft-delete path - -- **Evidence:** reproduced live. The failure is `OMAG-REPOSITORY-HANDLER-400-010` when the delete takes the soft-delete (Memento) path, which it does for an asset that lineage relationships point at. The failure is **not atomic**: the anchored `Endpoint` had already been soft-deleted when the call errored, leaving the asset and its Connection live. A fresh asset with the identical call purges cleanly. -- **Cause:** inferred from the error and timestamps, not confirmed in source: the cascade re-reads anchored elements it has just marked with Memento using the caller's `forLineage=false`. -- **Impact:** a half-deleted state. **Workaround confirmed:** repeat the delete with `forLineage: true`. -- **Fix status: not addressed.** A search of commit messages since 2026-10-02 for memento / soft-delete / cascade / forLineage finds nothing. (That is a message search, not a code diff.) -- **Upstream:** not yet reported. -- **Egeria team response (2026-10-05):** valid; the cause is the `qualifiedName` rename that happens *after* the Memento classification in `archiveBeanInRepository`: the re-read uses `forLineage=false`, so the Memento'd element is invisible and the first member (the Endpoint) fails with 400-010. There is also a silent defect: the **top-level archived asset is never renamed** (the generic `OpenMetadataRoot` type fails the `Referenceable` test). Fix in source on `oak2026`, pending merge: a two-pass archive (collect, then archive deepest-first, renaming before the Memento), internal reads with `forLineage=true`, the top-level asset renamed, and retries that finish a half-done archive. - -### 5. ISSUE-79: native survey of a template-created `FileFolder` fails - -- **Live result 2026-10-06:** with current pyegeria (no `deepCopy` in the request) a folder created from the File System Directory template **has 1 connection (`ResourceConnection`)**, read back through the classification explorer; it was then deleted and verified gone. **This confirms the `deepCopy:false` default as the cause of the missing connection.** The survey was not run, so "the survey completes" remains unproven. -- **Evidence:** reproduced live 2026-08-27, re-checked 2026-08-28 with an identical failure (`assetConnector` null in `BasicFolderConnector.getFile()`). The Egeria team (2026-08-30) found the originally recorded cause ("template creation never wires a Connection") to be **false**, fixed a related NPE, and left the reported failure open. -- **Impact:** blocks surveying those folders. -- **Fix status: probably a pyegeria bug, now fixed on our side; not yet shown live.** The Egeria team points to `e01426db86` (2026-08-30: PostgreSQL supertype-chain repair on server start after the 08-27 `ResourceConnection` re-parenting, plus a clearer "no connector for asset" error) and asked us to check that pyegeria did not send `deepCopy:false`. **It did.** `TemplateRequestBody.deep_copy` defaulted to `False` from 2026-01-09 until it was fixed on 2026-09-29 (#399, first released in v6.1.23), and the model is serialised with `exclude_none`, which keeps `False`. The report's helper, `create_folder_element_from_template`, builds its body without `deepCopy`, so every folder it created sent `"deepCopy": false`; Egeria then copies only the top-level element, **no `ResourceConnection`**, which is exactly a null `assetConnector` in `BasicFolderConnector.getFile()`. That fits the Egeria team's own observation that connector-created folders all had a connection. **To confirm:** create a folder from the template with current pyegeria, check it has a `ResourceConnection`, then survey it (a write window). The Egeria server fix may matter too, but it is no longer the first suspect. - -### 6. ISSUE-125: `deleteEnumDef` answers 500 for a listed enum - -- **Evidence:** live, 2026-10-05. After `add_enum_def`, an entity type using the enum, and a successful `delete_type_def` of that type, the enum delete answered `OMRS-CONTENT-MANAGER-500-001 ... getAttributeTypeDef has detected an unknown TypeDef ... on behalf of method deleteAttributeTypeDef`. `get_attribute_types` still lists the enum. -- **Cause (found by the Egeria team; I confirmed it in source at `449ad06894`):** `OMRSRepositoryContentValidator.java:877` calls `repositoryContentManager.getAttributeTypeDef(sourceName, guidParameterName, guid, methodName)`, but that 4-argument overload is `(sourceName, attributeTypeDefGUID, attributeTypeDefName, methodName)`. So the "GUID" passed is the *parameter-name string* and the "name" is the real GUID, which is exactly why the error text prints our real GUID as the unknown type. Every `deleteAttributeTypeDef` through the local repository fails (and `reIdentifyAttributeTypeDef` and the enterprise equivalents). **My earlier theory (a GUID map written in only one place) was wrong.** -- **Impact:** an enum added through the API cannot be removed. **A stray throwaway enum, `PyegeriaTmpCuisineType` (`118441be-6e03-4442-96c6-e431f75fcb3f`), is left on the shared dev platform**; the Egeria team says it is deletable only after a build containing the fix is deployed. -- **Fix status:** the Egeria team has the fix in source on `oak2026`, pending merge to `main`; **no build contains it**. -- **Re-tested after the redeploy (2026-10-05, build of 14:19 UTC from `449ad06894`, `egeria-main` restarted 14:39 UTC):** the enum **survived the restart** (still listed by `get_attribute_types`: API-defined types do persist), and `delete_enum_def` failed with the **identical** `OMRS-CONTENT-MANAGER-500-001 ... unknown TypeDef 118441be-... on behalf of method deleteAttributeTypeDef`. This is now explained: the failure is the argument-order bug above, which does not depend on what was loaded at startup. -- **Upstream:** not yet reported. - ---- - -## Addressed (or appear to be) - -### 7. ISSUE-95: no catalog template for "Apache Kafka Server" - -- **Status: addressed on the dev platform, confirmed live.** The running platform now resolves a template: `get_template_guid_for_technology_type("Apache Kafka Server")` returns `5e1ff810-5418-43f7-b7c4-e6e062f9aff7`. Egeria's source at `449ad06894` also ships `ApacheKafkaContentPack.omarchive` (109 mentions of "Apache Kafka Server"). This looks like a content-pack loading matter rather than a code defect; the log said the owner was investigating. -- **Follow-up:** `Create Kafka Server Element` can be re-tested live. - -### 8. ISSUE-85: no REST endpoint to create a `SolutionPort` - -- **Status: addressed in the server.** At `449ad06894`, `createSolutionPort` and `createSolutionPortFromTemplate` exist, with endpoints `POST /solution-ports`, `/solution-ports/from-template`, `/solution-ports/{guid}/update`, `.../delete`, `/by-name`, `/by-search-string` and `.../retrieve`. They first appear in commit `571034df11` (2026-09-06), three days after the issue was logged. **Live probe:** the running platform answers `POST /solution-ports/by-name` with a 200, so those endpoints exist there too. -- **pyegeria follow-up, not an Egeria bug:** the refreshed `.http` snapshot lists none of these endpoints and `pyegeria/omvs/solution_architect.py` has no `create_solution_port` (or update, delete, find). This belongs on the audit triage list. - -### 9. ISSUE-89: no configurable bearer-token lifetime - -- **Status: addressed in source.** Commit `a1f228d4a9` (2026-09-19, "Add control of bearer token timeout") added a `bearerTokenTimeout` property, read by `TokenService`, in **hours** with a default of 1, present in `application.properties` and `container.application.properties`. The request asked for seconds; Egeria chose hours. -- **Not covered:** a token refresh operation (the issue's optional second ask). The signing key changes on every restart, and **`rsa.key-id` does not prevent that** (confirmed in `RSAGenerator.generateRSAKeyPair`: it always makes a fresh key pair and only uses the id as a label); the Egeria team plans to persist the signing key in the next release. **Not verified on the dev platform**, whose image may predate the change. - -### 10. ISSUE-102: `MemberDataField.minCardinality` silently persisted as `maxCardinality` - -- **Original finding (2026-09-17):** with a raw request, `position=3, minCardinality=1, maxCardinality=5` read back as `minCardinality=5`, with no error. -- **Raw capture for the Egeria team (2026-10-06):** one more link with the exact request `position 3, minCardinality 1, maxCardinality 5` (answer `VoidResponse`) and a read-back through the endpoints lookup (`OpenMetadataRelationshipListResponse`) returned `minCardinality "1"`, `maxCardinality "5"`: still no repro, now with raw request, response and read-back recorded (local file `live_102_raw.out`; their three asks are met). -- **Re-tested live after the redeploy (2026-10-05, build of 14:19 UTC from `449ad06894`):** one throwaway `DataStructure` and four `DataField`s were linked with `MemberDataField` and each relationship was read back through the endpoints lookup. **All four stored correctly**; `position` was right every time: - - | sent (min, max) | stored (min, max) | - |---|---| - | 1, 5 | 1, 5 | - | 2, 7 | 2, 7 | - | 0, 5 | 0, 5 | - | 3, *omitted* | 3, 0 | - - Everything was deleted child-first and verified gone; no leftovers. -- **Status: no longer reproduces.** I cannot say *why*. My earlier source comparison found no change to `MemberDataFieldProperties`, `PartOfRelationshipProperties`, the read converter or the relationship builder, and called the bug "not addressed". That call was wrong. Either the fix is in code I did not inspect, or the build that showed the bug on 2026-09-17 was older than my 2026-09-15 baseline. It would be worth asking the Egeria team which change fixed it before closing the issue for good. -- **A side observation, not part of this bug:** when `maxCardinality` is omitted it is stored as `0`, which sits below a supplied minimum (case 4). The bean's default is `0` and its documentation says `-1` means unlimited, so an omitted maximum silently becomes "at most zero". That is plausibly a separate wart, not something I have validated further. - ---- -- **Egeria team response (2026-10-05):** **not reproduced** in Egeria. They traced every layer, and a server-side builder-plus-converter round trip returns `position=3, min=1, max=5`; the layers below the builder store properties by name and were not traced. They asked for the exact request body, the raw response before pyegeria formatting, and the read-back endpoint, to tell a client-side formatting fault from a read-path fault. **Our answer:** the request was `NewRelationshipRequestBody` with `properties` `{class: MemberDataFieldProperties, position: 3, minCardinality: 1, maxCardinality: 5}` sent through `DataDesigner._async_link_member_data_field`. The original raw response was **not captured** on 2026-09-17 (the entry's read-back shows camelCase property names, which suggests a raw property read, but I cannot prove which call). On the 2026-10-05 build it does **not** reproduce for us either. A fresh raw capture on the current build is possible if useful. - -## Reported but not validated - -### ISSUE-108: relationships invisible to related-element queries for up to ~20 minutes - -- One report from a Dr.Egeria bulk load: 876 of 1,027 expected links visible immediately, 82 structures still short at 12 minutes, all present at 20 minutes, with no errors at any point. Not independently reproduced. Two unconfirmed leads are on record (Kafka rebalance storms, and a fixed wall-clock delay), and the log's own next step is a smaller, timed, instrumented reproduction. -- **Cannot be assessed against source without a reproduction.** If real it would rank high, because it produces false "missing" results after a bulk load. -- **Egeria team response (2026-10-05):** **not validated**; no cache found. Best lead: a client clock ahead of the server's, with `effectiveFrom` set from it (related-element queries hide a relationship whose `effectiveFrom` is later than the server's "now", silently). They need, for one link still missing at about 12 minutes: its `effectiveFrom` and `createTime`, the server clock at that moment, and whether the loader sets `effectiveFrom` at all. **Our facts:** pyegeria sets **no** `effectiveFrom`, `effectiveTo` or `effectiveTime` by default (the model defaults are `None`, no clock call is tied to any `effective*` field, and Dr.Egeria forwards an "Effective From" only if the author typed one), so the lead needs a load document that set it. Host and container clocks agree within 1 s now; whether they did on 2026-09-20 cannot be checked, and Docker Desktop VM clock drift after laptop sleep is a hypothesis I have not measured. The load's `effectiveFrom` and `createTime` values are not available to me. - -### Two further reports from the Resource Explorer coordinator's JDBC cataloguer scratch test (2026-10-05) - -Reported by the Coordinator session after its own live run on the rebuilt platform. **Not reproduced by me and not yet in `PYEGERIA_ISSUES.md`**; recorded here as leads, with the Coordinator's wording. - -- **`/archive` endpoint answers 500.** Archiving a `DeployedDatabaseSchema` through the view server fails with a `DeployedRequestBody` class-name error, on the build running since 14:39 UTC. -- **An array `includeSchemaNames` in a survey's own connection configuration is ignored.** The survey runs but does not restrict itself to the listed schemas. - -Both need a minimal reproduction (the request body and the response) before they can be ranked or filed. - ---- - -## Re-check at `449ad06894` - -Run against the pulled source on 2026-10-05. Each line is what was measured; "unchanged" means the defect's code path is as described above. - -| Issue | Measured at `449ad06894` | Result | -|---|---|---| -| 124 | `OMRSTypeDefConverter.getTypeDefPatch`: `setUpdatedBy` occurrences = 0 | unchanged, still missing; **live re-test after redeploy confirms it still fails** | -| 125 | `OMRSRepositoryContentValidator.java:877` calls `getAttributeTypeDef(sourceName, guidParameterName, guid, methodName)`; the overload is `(sourceName, guid, name, methodName)` | unchanged, and **this is the real cause** (found by the Egeria team, confirmed here); our earlier GUID-map explanation was wrong | -| 112 | `AutomatedCuration...RESTServices`: the `instanceof YAMLSecretsFileConnector` block (line 480) has no `else` | unchanged | -| 90 | `startMissedEngineActions` vs 2026-09-15: 11 changed lines, all in the per-action `catch` (`logException` to `logMessage`); the outer `catch` that aborts the pass is untouched | unchanged apart from less log output | -| 102 | `MemberDataFieldProperties` and `PartOfRelationshipProperties`: 0 commits since 2026-09-15 | source unchanged, **yet the bug no longer reproduces live** (section 10): the source comparison gave a false "not addressed" | -| 117 | commit messages since 2026-10-02 matching memento / soft-delete / cascade / forLineage: 0 | unchanged | -| 79 | `BasicFolderConnector.java`: 0 commits since 2026-09-15 | unchanged in that file; the Egeria team points to `e01426db86` (2026-08-30) and to our own `deepCopy:false` default (section 5) | -| 85 | `createSolutionPort(` present in `SolutionArchitectRESTServices` | still addressed | -| 89 | `bearerTokenTimeout` present in `application.properties` | still addressed | -| 95 | (live) template lookup resolves | still addressed | - -## Live re-test plan after the redeploy - -Nothing here has been run against a build containing `449ad06894`. Items marked **write** create and then remove throwaway elements, so they need a coordinated write window on the shared platform. - -| Issue | Test | Kind | If fixed, expect | -|---|---|---|---| -| 125 | First confirm the stray enum `PyegeriaTmpCuisineType` (`118441be-6e03-4442-96c6-e431f75fcb3f`) is still listed by `get_attribute_types`, then retry `delete_enum_def` | read-only, then one **write** | the enum survives a redeploy (types persist), and the delete now succeeds. **DONE 2026-10-05: it survived; the delete still fails identically.** | -| 124 | Add a throwaway entity type (no enum), send a patch that adds one attribute, read back, delete it | **write** | the patch is accepted and the new attribute appears in version 2. **DONE 2026-10-05: still rejected with the same `updatedBy` error.** | -| 102 | Link a throwaway `DataField` to a `DataStructure` with `position=3, minCardinality=1, maxCardinality=5`, read the relationship back | **write** | `minCardinality` reads back as 1, not 5. **DONE 2026-10-05: reads back correctly in all four cases; no longer reproduces. 2026-10-06: raw request/response captured, same result.** | -| 112 | Call `saveClientSideSecret` against a secrets store whose connection resolves to a non-YAML connector | **write** | an error, not a silent success | -| 117 | Cascade-delete an asset that is a subscription destination, with `forLineage=false` | **write** | the delete completes, or fails atomically | -| 79 | Create a folder from the template with current pyegeria (deepCopy omitted), check it has a `ResourceConnection`, then initiate a native survey on it | **write** (creates an element and an engine action) | a connection is present and the survey completes, with no null `assetConnector`. If it fails only on a build without `e01426db86`, the server fix matters too **Connection check DONE 2026-10-06: present. Survey not run.** | -| 90 | Watch `qs-engine-host` logs for `ENGINE-HOST-SERVICES-2002` repeating, and container CPU, over ten minutes | read-only | no repeating refusal. Note it depends on startup history, so a clean run proves little. **DONE 2026-10-05: clean, but no `APPROVED` engine action existed to trigger it, so inconclusive. A real test needs an `APPROVED` action anchored to an element the engine-host user cannot read.** | -| 85 | Create a throwaway `SolutionPort`, read it back, delete it | **write** | create succeeds (the by-name read already answers 200) | -| 89 | Set `bearerTokenTimeout` to a non-default value, restart, decode a token's `exp - iat` | config change and restart | the lifetime follows the property (hours) | -| 95 | Re-run the Kafka template lookup, then `Create Kafka Server Element` | read-only, then **write** | the lookup resolves (it already does) and the element is created | -| 108 | A timed, instrumented bulk link load, polling related-element queries each minute | **write** | all links visible promptly (this one is not yet validated at all) | - -The refreshed `.http` collection has not been updated yet; once it has, the new endpoints (for example the `SolutionPort` set) should be checked against it as well. - ---- - -## Method and limits - -- The ten validated items come from the issues log; ISSUE-124 and ISSUE-125 were found and live-tested in this session, so their evidence is first-hand. I did **not** re-test the older items live today. -- Fix status comes from comparing the source at `449ad06894` with the 2026-09-15 checkout for the specific files involved, searching commit messages, and reading the code. Source comparison can show that a fix exists but not that a given platform build contains it. -- Live checks: two read-only probes on the 2026-10-03 build (`POST /solution-ports/by-name`, the Kafka template lookup), then three write re-tests on the **rebuilt** platform (ISSUE-125, 124 and 102), each cleaned up and verified gone by GUID, and one read-only check of the rebuilt platform's logs, CPU and active engine actions (ISSUE-90). -- Commit-message searches (ISSUE-117) find nothing relevant, but a message search is weaker than reading the diff; a fix could be hiding under an unrelated message. -- `~/localGit/egeria-v6/egeria` is still on the 2026-09-15 commit (70 commits behind); the pulled copy is `~/localGit/egeria-v5-1/egeria-aug-5-24`.