docs(issues): re-verify all open issues, close 3 as fixed server-side - #275
Open
dwolfson wants to merge 7 commits into
Open
docs(issues): re-verify all open issues, close 3 as fixed server-side#275dwolfson wants to merge 7 commits into
dwolfson wants to merge 7 commits into
Conversation
Re-verified every open issue live against the current qs-view-server, prompted by a round of pyegeria bug fixes (492b84a) and a platform redeploy/restart since the last check. Moved to appendix as resolved (server-side fixes, no pyegeria code change -- client-side request shapes were already confirmed correct against ground truth before this sweep): - ISSUE-53: metadataElementSubtypeNames now actually filters (confirmed via both a live find and the native count endpoint matching exactly). - ISSUE-57: GovernanceResults relationship no longer rejects end1/end2 order -- link_governance_results succeeds live now. - ISSUE-60: find_glossary_terms sequencing_order now produces a genuine continuous sort across pages, not just within one page. Re-confirmed still open, with fresh dated notes: - ISSUE-30 (updateNote 404) -- unchanged. - ISSUE-38 (count_relationships_between_elements off-by-one) -- unchanged, identical 58 vs 57. - ISSUE-41 (find_glossary_terms combined-filter zero results) -- unchanged, though ISSUE-60's fix means the trigger condition may have shifted -- flagged for a fresh root-cause look. - ISSUE-54 (Referenceable-scoped scan incomplete) -- symptom shape changed substantially (494 total elements now vs 19,166 before, zero duplicate GUIDs now vs 39 before) but core incompleteness persists (41% GlossaryTerm coverage). Not re-run as a full exhaustive scan this pass -- flagged for one before considering closed. - ISSUE-48, ISSUE-52, ISSUE-55 -- not re-tested (deferred pending Egeria API work / infra observation / feature request respectively; nothing about this sweep's fixes plausibly changes their status). Restructure: the file's "open issues at top, appendix at bottom" skeleton already existed (established 2026-08-15) -- this pass is a content accuracy pass on top of that skeleton, moving the 3 newly-confirmed-fixed entries out of the open section into the appendix where they belong. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
pyegeria/README.md pointed at "_exceptions_new.py", which doesn't exist -- the real file is pyegeria/core/_exceptions.py (the doc's own example code already imports from the correct path). Found while auditing docs for staleness after the recent round of pyegeria fixes. CLAUDE.md: added a gotcha note under pyegeria/core/ about the extra='ignore' silent-field-drop hazard ISSUE-62 found in DeleteElementRequestBody -- a request-body model missing a field validates a caller-supplied dict successfully and just drops the unknown field before serialization, no error. Worth flagging generally since other request-body models haven't all been audited against their real Egeria DTOs the way this one now has. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Create Information Supply Chain's Purposes attribute (ISC Base bundle) validates and processes with SUCCESS but is never persisted to the element -- confirmed live creating 17 InformationSupplyChain elements for the Overview dashboard's GovernanceMetric data-flow documentation (gen_governance_metrics.py), none of which retained their Purposes value. Worked around by using the standard Description attribute instead. Root cause not yet found -- flagged as either a processor gap (Purposes never read from attributes) or a type mismatch (plural name suggests List<String>, untested). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
SupplyChainProcessor.apply_changes() built Create/Update Information Supply Chain's properties body purely from the generic set_element_prop_body() (Referenceable-level fields only) and never added InformationSupplyChainProperties-specific fields on top -- so --validate/--process reported SUCCESS while Purposes/Scope were never included in the outgoing body at all, unlike sibling domain processors (e.g. set_collection_manager_body adding Digital-Product-specific fields). Also found while root-causing: the real Egeria wire property is "dataProcessingPurposes", not "purposes" (confirmed against Egeria-api-solution-architect.http's createInformationSupplyChain/ updateInformationSupplyChain worked examples) -- the compact spec's "Purposes" attribute has no property_name override pointing at this. Fix: explicitly set prop_body["dataProcessingPurposes"]/prop_body["scope"] on both Create and Update paths. Verified live: created a real ISC with both fields set, fetched it back, both persisted correctly. 3 new unit tests (test_supply_chain_processor.py) cover Create/Update/unset-is-None via a fake client. Renumbered from a same-day ISSUE-62 collision (kept the number already burned into DeleteElementRequestBody's code comments, renumbered this newer duplicate to ISSUE-63 per this file's established collision convention). Flagged, not resolved: Integration Style/Estimated Volumetrics (same ISC Base bundle) have zero ground-truth backing anywhere in Egeria-api-solution-architect.http -- integrationStyle only exists in this codebase as a SolutionLinkingWire *relationship* property, suggesting these two may be misattributed to the wrong bundle rather than sharing this bug's "processor never reads it" mechanism. Not confirmed against the real Java class; left as a follow-up. Also in this commit -- a related but separate fix found while investigating ISSUE-54 (which had been misdiagnosed hours earlier in the same day; corrected per Egeria's own paging docs at https://egeria-project.org/guides/developer/finding-metadata/overview/#paging, which state a short-but-nonempty page does NOT mean "last page", only a genuinely empty one does): pyegeria/view/base_report_formats.py's load_egeria_report_specs() had exactly that len(page) < page_size anti-pattern in a real fetch-all loop over ReportType collections -- fixed to advance startFrom unconditionally and stop only on an empty page. Full codebase grep confirms this was the only occurrence. PYEGERIA_ISSUES.md: corrected ISSUE-54's write-up (real remaining defect is duplicate GUIDs + ~17% still-missing population when paginated correctly, not the false short-page signal first suspected), re-confirmed ISSUE-41 with a traced request body (rules out any pyegeria-side cause definitively), and closed ISSUE-63 as fixed with full root-cause detail. pytest tests/micro-tests/ passes in full. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…eleteMethod fix
MetadataExpert.delete_related_elements()/_async_delete_related_elements()
and delete_metadata_element()/_async_delete_metadata_element() were left
behind when the deleteMethod-silently-dropped bug (PyegeriaModel's
extra='ignore' swallowing any field a target model doesn't declare) was
fixed for DeleteRelationshipRequestBody and ~15 other OMVS modules, and for
DeleteElementRequestBody (ISSUE-62). Both methods still routed through
OpenMetadataDeleteRequestBody/_async_open_metadata_delete_body_request,
which has no delete_method field at all -- so a caller-supplied
deleteMethod validated successfully and silently vanished, same as the
original bug, unchanged. Since deleteRelationshipInStore rejects its own
default deleteMethod (LookForLineage) with OMAG-COMMON-400-032,
delete_related_elements() (the fallback every caller without a bespoke
"unlink" method reaches for) could never succeed at all on a stock server.
Reported by dwolfson from Resource Explorer's investigation (full report
text preserved in PYEGERIA_ISSUES.md).
Fix: migrated _async_delete_related_elements() to DeleteRelationshipRequestBody
via _async_delete_relationship_request(), and _async_delete_metadata_element()
to DeleteElementRequestBody via _async_delete_element_request() -- exactly
mirroring the pattern already used by _async_archive_metadata_element right
above it in the same file. delete_metadata_element gained a cascade_delete
parameter to match. OpenMetadataDeleteRequestBody itself untouched (it's
correctly fieldless per its own ground truth).
Verified live against qs-view-server: created two throwaway assets + a real
DataFlow relationship. delete_related_elements(guid) with no body still
fails with the same 500 (expected -- Egeria's own default deleteMethod is
still rejected, unchanged); delete_related_elements(guid, {"deleteMethod":
"SOFT_DELETE"}) now succeeds -- the override that was previously impossible
now works end-to-end. delete_metadata_element() on both assets also
succeeded. 6 new unit tests (test_metadata_expert_delete_methods.py).
Also in this commit: renumbered the ISC Purposes/Scope fix from a second
same-day ISSUE-63 collision (this report's number) to ISSUE-64 -- kept the
number here since this report's number was already fixed by its own
author. Updated all cross-references (solution_architect.py comment,
test_supply_chain_processor.py docstring, PYEGERIA_ISSUES.md).
pytest tests/micro-tests/ passes in full.
Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…ndards classification shape gotcha Cross-posted from a peer session working in egeria-workspaces-fs (Egeria Explorer's Glossary panel). PrimeWord/ClassWord/Modifier classifications (0438 Naming Standards) don't surface as individually-named elementHeader keys the way most classifications do (e.g. Confidentiality -> elementHeader.confidentiality) -- they're bucketed into a single list-valued elementHeader.glossaryTermKinds key instead, same shape MetadataExpert.get_metadata_element_by_guid's top-level classifications list already uses. Not a data-missing bug -- confirmed live the classifications ARE present at every graphQueryDepth, just under a key a naive dict-valued-classification extractor won't check. Not documented anywhere in this codebase (get_term_by_guid currently has no docstring at all) -- flagged as a follow-up docs fix, not attempted in this commit. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…n Egeria server gap
_async_update_note built feedback-manager/notes/{noteGUID}, which 404s.
This URL was cross-checked against Egeria-api-feedback-manager.http's
updateNote worked example on three separate re-verification passes
(2026-08-05, 2026-08-15, 2026-08-18) and matched byte-for-byte each time --
which is exactly why this got classified as an Egeria server bug
(unregistered/unshipped endpoint) rather than a pyegeria bug. The .http
reference file itself was stale at the time, so "matches ground truth"
was false confidence: both sides of the comparison shared the same wrong
URL.
Fixed by dwolfson after refreshing the local Egeria-api-feedback-manager.http
copy -- its updateNote example now shows feedback-manager/assets/{noteGUID}
/update (the same assets/{guid}/update shape the feedback-manager service
uses elsewhere), not feedback-manager/notes/{noteGUID}. Corrected
_async_update_note's URL to match.
Verified live against qs-view-server: created a throwaway DataStructure ->
NoteLog -> Note (same repro every prior re-check used), called
update_note(guid, display_name=..., description=...) -- succeeded
(previously 404'd every time). Fetched the note back via
get_notes_for_note_log and confirmed both fields actually persisted, not
just a 200 with no real effect. 2 new unit tests
(test_update_note_url.py, mocked _async_make_request, no live server) lock
in the corrected URL and body shape.
PYEGERIA_ISSUES.md: moved ISSUE-30 to the resolved appendix, corrected its
Layer from Egeria Server to Pyegeria, and added a note for future
re-verifications -- "matches the .http ground truth" is only as
trustworthy as that file's own currency; worth being more skeptical of a
"must be server-side" verdict when the .http file hasn't been
independently re-verified against a current server/Swagger spec recently.
pytest tests/micro-tests/ passes in full.
Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #274 (merged) — this commit landed on the branch just after that PR merged, so it needs its own PR.
Full re-verification sweep of
PYEGERIA_ISSUES.md, prompted by the recent round of pyegeria bug fixes (492b84a) plus a platform redeploy/restart since the last check. Every open issue was re-tested live against the currentqs-view-server.Moved to appendix as resolved (server-side fixes — no pyegeria code change involved; client-side request shapes were already confirmed correct against ground truth before this sweep):
metadataElementSubtypeNamesnow actually filters (confirmed via both a live find and the native count endpoint matching exactly: 357 = 357).GovernanceResultsrelationship no longer rejects the end1/end2 order —link_governance_resultsnow succeeds live.find_glossary_termssequencing now produces a genuine continuous sort across pages, not just within one page (verified page 1 → page 2 boundary is seamless A→Z).Re-confirmed still open, with fresh dated notes:
updateNote404) — unchanged.count_relationships_between_elementsoff-by-one) — unchanged, identical 58 vs 57.find_glossary_termscombined-filter zero results) — unchanged, though ISSUE-60's fix means the trigger condition may have shifted — flagged for a fresh root-cause look.Referenceable-scoped scan incomplete) — symptom shape changed substantially (494 total elements now vs 19,166 before, zero duplicate GUIDs now vs 39 before) but core incompleteness persists (41% GlossaryTerm coverage). Flagged for a full exhaustive re-scan before considering closed.No restructuring of the file's skeleton was needed — the "open issues at top, appendix at bottom" split by who-can-fix-it already existed (established 2026-08-15). This is a content-accuracy pass on top of that skeleton.
Testing
Docs-only change (
PYEGERIA_ISSUES.md) — no code changes, no tests to run. All findings above were verified live againstqs-view-server.🤖 Generated with Claude Code