Repository navigation
docs(issues): Egeria team confirms ISSUE-52, ISSUE-54, ISSUE-41/PY-21 fixed server-side -- move to Fixed/Resolved - #332
Merged
Conversation
… fixed server-side -- move to Fixed/Resolved Prepends Mandy Chessell's (Egeria team) 2026-08-30 updates to all three entries, verbatim per her own instructions, then moves each from 'Open Egeria Server issues' to the 'Fixed / Resolved' appendix -- all existing history preserved underneath, nothing deleted. ISSUE-52 (background connector load): the JDBC transaction leak this entry identified (connections stuck idle in transaction) was fixed the same day it was found, 2026-08-16 (a4ab1c090a/7359136cb1/c52c1ba8bd) -- the 6.2-SNAPSHOT build later re-checks ran against already carried the fix, consistent with the acute symptom having stopped reproducing. ISSUE-54 (findMetadataElements incomplete population): root cause confirmed in source, 0d8d079c50 -- ORDER BY on a non-unique column plus LIMIT/OFFSET paging let tied rows be ordered differently per page fetch, so elements could be skipped or double-counted across pages while the traversal reported nothing wrong. Fixed by always appending the table's primary key to ORDER BY. Regression-covered by a new PagingStabilityFVT. Not yet re-measured against the ~9,600-element Referenceable population this entry's own numbers came from -- noted as still worth doing. ISSUE-41/PY-21 (sequencing_order + classification filter -> zero results): root cause was never sequencing_order -- includeOnlyClassifiedElements/skipClassifiedElements were never pushed into the by-search-string query at all; the repository picked the page first and filtered after, so whichever elements happened to land on page 1 determined the result. Fixed in the same commit as ISSUE-54, 0d8d079c50. Regression-covered by a new ClassificationFilterPushdownFVT. Includes a concrete pyegeria follow-on for egeria-workspaces-fs's perspectives_handler.py once verified. EGERIA_OPEN_ISSUES.md refreshed from the updated source section -- down to 2 entries (ISSUE-38, ISSUE-79), both explicitly kept open pending pyegeria-side verification or because the real cause is still unresolved. 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
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
Prepends Mandy Chessell's (Egeria team) 2026-08-30 updates to all three
entries, verbatim per her own instructions, then moves each from "Open
Egeria Server issues" to the "Fixed / Resolved" appendix -- all existing
history preserved underneath, nothing deleted.
pressure): the JDBC transaction leak this entry identified (connections
stuck idle in transaction) was fixed the same day it was found,
2026-08-16 (
a4ab1c090a/7359136cb1/c52c1ba8bd) -- the 6.2-SNAPSHOTbuild later re-checks ran against already carried the fix, consistent
with the acute symptom having stopped reproducing.
findMetadataElementsincomplete population, ~70%coverage): root cause confirmed in source,
0d8d079c50--ORDER BYona non-unique column plus
LIMIT/OFFSETpaging let tied rows beordered differently per page fetch, so elements could be skipped or
double-counted across pages while the traversal reported nothing wrong.
Fixed by always appending the table's primary key to
ORDER BY.Regression-covered by a new
PagingStabilityFVT. Not yet re-measuredagainst the ~9,600-element
Referenceablepopulation this entry's ownnumbers came from -- noted in the entry as still worth doing.
sequencing_order+ classification filter -> zeroresults): root cause was never
sequencing_order--includeOnlyClassifiedElements/skipClassifiedElementswere never pushed into the by-search-stringquery at all; the repository picked the page first and filtered after,
so whichever elements happened to land on page 1 determined the result.
Fixed in the same commit as ISSUE-54. Regression-covered by a new
ClassificationFilterPushdownFVT. Includes a concrete pyegeriafollow-on for egeria-workspaces-fs's
perspectives_handler.pyonceverified.
EGERIA_OPEN_ISSUES.mdrefreshed from the updated source section -- downto 2 entries (ISSUE-38, ISSUE-79), both explicitly kept open pending
pyegeria-side verification or because the real cause is still unresolved.
Docs only, no code changes.
🤖 Generated with Claude Code