Fixes #29687: glossary term inverse relation types show wrong perspective - #32891
Fixes #29687: glossary term inverse relation types show wrong perspective#32891anuj-kumary wants to merge 3 commits into
Conversation
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
✅ Playwright Results — workflow succeededValidated commit ✅ 561 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky PerformanceBlocking targets: ✅ met · Optimization targets: 🟡 in progress Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting. 🕒 Full workflow signal wall (to summary) 44m 56s ⏱️ Max setup 4m 9s · max shard execution 19m 11s · max shard-job elapsed before upload 22m 18s · reporting 3s 🌐 234.33 requests/attempt · 2.81 app boots/UI scenario · 8.43% common-shard skew Optimization targets still in progress:
How to debug locally# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip # view trace |
…tive The existence check in `addTermRelation` compared user-authored types against already-inverted display types from `getRelatedTerms()`, failing to detect duplicates when the user's type was the inverse of the stored canonical type. The same mismatch affected `matchesRelation` used by the remove endpoint. Add `isEquivalentRelationType` that treats a type and its registered inverse as equivalent for these comparisons. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…d types Address gitar-bot review findings: - Check inverse in both directions so one-directional custom inverse registrations are still deduped/matched - Guard inverse lookup so unregistered types return no-match instead of throwing BadRequestException Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
a48ddde to
a7cfbbb
Compare
77f2856 to
01979eb
Compare
…both sides Add E2E tests for #29687 that verify the UI shows the correct relation perspective on each side of an asymmetric relation (narrower/broader, hasPart/partOf) and that the correct type persists after page reload. Uses the base fixture with serverLoadReducers, beforeAll/afterAll API setup via getDefaultAdminAPIContext, addTermRelation API utility, and term.visitEntityPage() for navigation — matching the established GlossaryRelationsGraph test patterns. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
01979eb to
1e7926c
Compare
Code Review ✅ ApprovedFixes inconsistent inverse relation display for custom glossary term relation types by making the equivalence check symmetric and safe for unregistered types. OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
Summary
Fixes #29687 — When custom glossary term relation types with inverses (e.g. “uses”/“usedIn”) are configured, both sides of a relation can show the same type instead of showing inverses. Editing the type reverts on page refresh. Root cause is UUID-ordering-dependent one pair works, another doesn’t.
Root cause:
addTermRelationandmatchesRelationcompare user-authored relation types against already-inverted display types returned bygetRelatedTerms(). When a user sends type"uses"but the existing relation displays as"usedIn"(after inverse resolution), the check incorrectly concludes the relation doesn't exist — potentially creating duplicate relations or failing to find existing ones for removal.Fix: Add
isEquivalentRelationType()that treats a type and its registered inverse as equivalent, and use it in:addTermRelationexistence check (prevents duplicate relations across inverse types)matchesRelation(makes removes robust against inverse type mismatches)The comparison is symmetric (checks inverse in both directions) and safe for unregistered types (catches
BadRequestExceptioninstead of throwing).Changes
GlossaryTermRepository.java— newisEquivalentRelationType+safeInverseNamehelpers; updatedaddTermRelationdedup check andmatchesRelationto use themGlossaryTermRelationEdgeIT.java— two new integration tests:customInverseRelationTypesPreserveCorrectPerspective— verifies both sides of narrower/broader relations show the correct perspective typeaddTermRelationDetectsDuplicateAcrossInverse— verifies the dedup check recognizes inverse types as equivalentTest plan
GlossaryTermRelationEdgeITtests pass (inverse behavior unchanged for correct cases)customInverseRelationTypesPreserveCorrectPerspectivetest passesaddTermRelationDetectsDuplicateAcrossInversetest passes🤖 Generated with Claude Code