dwolfson · Oct 24, 2026 · Oct 23, 2026
@@ -24,7 +24,7 @@ Mandy will expose more engine-host internal APIs as View Server REST calls once
 
 Once the Egeria release with the delete fixes is published and the local quickstart is redeployed:
 
-1. **ISSUE-146:** re-test `remove_note`, which now posts to `metadata-expert/metadata-elements/{guid}/delete`, against test JournalEntry `8bec72e4-6da6-40a4-943e-d81e2173ec9b` on Erin's profile (`10dc7da9`). Try a plain delete first, then `deleteMethod: ARCHIVE` if it still fails with `OMAG-REPOSITORY-HANDLER-400-008`. Tell the egeria-workspaces-fs session before deleting anything on Erin's profile. Keep `fef83ed5` (owner's decision).
+1. **ISSUE-146** (after the 2026-10-23 Egeria reset, the test entries named here no longer exist; use a fresh `journal_my_activity` entry): re-test `remove_note`, which now posts to `metadata-expert/metadata-elements/{guid}/delete`, against test JournalEntry `8bec72e4-6da6-40a4-943e-d81e2173ec9b` on Erin's profile (`10dc7da9`). Try a plain delete first, then `deleteMethod: ARCHIVE` if it still fails with `OMAG-REPOSITORY-HANDLER-400-008`. Tell the egeria-workspaces-fs session before deleting anything on Erin's profile. Keep `fef83ed5` (owner's decision).
 2. **Other delete issues** to re-check at the same time: ISSUE-117 (Memento cascade delete), ISSUE-125 (`deleteEnumDef`) and ISSUE-132 (`cascadedDelete` field name).
    Also ISSUE-147, the valid-metadata clears: re-run the ISSUE-147 sequence (setup then clear for a value, a map name and a map value on a made-up property). Expect no 400-011 error after a successful clear, and expect the map value to actually be removed.
 3. Update each `PYEGERIA_ISSUES.md` entry with the result, and include any fixes in the next release after 6.2.5. (6.2.6, 2026-10-19, ships the ISSUE-156 catalog-target and ISSUE-157 Service Level Objective fixes from #464; the re-tests needed no pyegeria change. 6.2.4, 2026-10-16, shipped only the My Profile My Network work from #458. 6.2.5, same day, ships only the ISSUE-153 GovernanceEngine client from #460; its release notes must say that AutomatedCuration's engine-action methods are deprecated and now call the governance-engine view service, falling back to the old automated-curation path on a 404. These re-tests are still blocked on Egeria. Owner, 2026-10-13: 6.2.3 ships now with the completed fixes instead of waiting for these re-tests, which are all blocked on Egeria. 6.2.3's release notes list the ISSUE-148 behaviour change and the ISSUE-151 API removal.)

@@ -849,6 +849,8 @@ Checked at egeria-python `f1b06cdd`; the installed wheel in trellis has the same
 
 ### 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 reset 2026-10-23 ~21:10-23:54Z** (egeria-workspaces-fs, owner-approved): the quickstart database was wiped and Egeria recreated on build 81beb8e5 (odpi/egeria 4486d1a7), then Coco content was reloaded. Every GUID recorded before then is gone. The test JournalEntries `fef83ed5` and `8bec72e4` on Erin's profile no longer exist, so the pending `remove_note` re-test below needs a NEW entry made with `journal_my_activity` (and, for the 400-008 case, one owned by an external source). The 2026-10-18 Egeria analysis (works as designed; 400-008 is the provenance check) still applies.
+
 **Egeria team, 2026-10-18 (Mandy Chessell, note saved at `~/.re-gate/EGERIA-TEAM-NOTE-2026-10-18.md`):** **Status now: works as designed (Egeria).** Asset Maker's `deleteAsset` is the right call: a JournalEntry is a Notification, so an asset, and no separate note delete is needed. Egeria's new FVT creates entries with My Profile's `journal-my-activity` and deletes them with `deleteAsset`, with no external source; every case passes on in-memory and PostgreSQL repositories. **400-008 is the provenance check:** it refuses a change made without an external source to an element an external source owns. No external source → 400-008; a different external source → 400-007; the matching external source → success. So an entry that returns 400-008 was not created locally, and its delete needs that entry's `externalSourceGUID` and `externalSourceName`. If 400-008 appears on an entry created through My Profile, that is a bug and Egeria wants: (1) the full error message (it names the type, GUID, provenance and metadata collection of the refused instance); (2) how the entry was created (which request, and which external source if any). Also new: purge applies the same provenance check. **pyegeria:** the `remove_note` clean-up below stays (route + docstring). Re-test on `8bec72e4` against a platform with the fixes; if 400-008 recurs, capture the full message for Egeria, since that entry was created locally through `journal-my-activity`.
 
 **Layer:** Egeria Server (pyegeria clean-up) · **Status:** open · **Found:** 2026-10-13, reported by the egeria-workspaces-fs Resource Browser session from a live private-journal test.
@@ -1832,6 +1834,8 @@ enough to track there too).
 
 ### 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
 
+**Egeria reset 2026-10-23 ~21:10-23:54Z** (egeria-workspaces-fs, owner-approved): the quickstart database was wiped and Egeria recreated on build 81beb8e5 (odpi/egeria 4486d1a7), then Coco content was reloaded. Every GUID recorded before then is gone. The leftover `pyegeriaClearRetest*` test elements described under "Leftovers on qs-view-server" are gone with it; nothing to clean up. The fix had already passed its 2026-10-19 re-test.
+
 **Egeria team, 2026-10-18 (Mandy Chessell, note saved at `~/.re-gate/EGERIA-TEAM-NOTE-2026-10-18.md`):** **Status now: fixed on Egeria's `oak2026` branch, pending its merge to `main`** (each fix has an FVT or unit test). Re-test once `oak2026` is merged and a platform is built from `main`. A successful clear now returns success; clear-map-value now uses the map name; clear-map-name also removes that map name's values. Egeria asks us to drop any workaround that treats 400-011 as success. **pyegeria:** there is none (checked 2026-10-18: no 400-011 handling in `md_processing/v2/reference_data.py` or `pyegeria/omvs/valid_metadata.py`), so the follow-on proposed below is withdrawn. Nothing to change; after the re-test, remove the leftover `pyegeriaClearRetest*` test elements on qs-view-server.
 
 **Re-test 2026-10-19 (quickstart recreated 13:02Z on Egeria `main` 05a5e982, image 6.3-SNAPSHOT built 2026-10-18 16:13Z; as erinoverview on qs-view-server; throwaways named `pyeg_rt_*`, each deleted and verified gone by GUID; peers cleared first):** **PASS.** On throwaway properties `pyegRtClear`/`pyegRtClearMap` (typeName Asset), `clear_valid_metadata_value` (alpha, beta), `clear_valid_metadata_map_value` (mapOne/v1) and `clear_valid_metadata_map_name` (mapTwo, mapOne) all return success. A second clear of an already-removed value still answers 400-011 "not found", which is correct. Values and map names were gone afterwards. One oddity: `get_valid_metadata_values` read in the same run straight after the clears still listed alpha/beta/mapOne/mapTwo, but a read a minute later was empty. Possibly a short server-side cache; not pursued. Setup creates per-property container sets (`Egeria:ValidMetadataValue::pyegRtClear-`, `...pyegRtClearMap-`) that the clears do not remove; deleted by GUID. **Not cleaned (outside what peers cleared):** the 2026-10-13 leftovers under `pyegeriaClearRetest*`, which the platform has since turned into DataProduct/DigitalProduct elements (e.g. `98de81ed`, `4b937012`).