DATA-CAT-001 — Use one canonical DataHub dataset identity
| Field | Value |
|---|---|
| Status | Open finding; source-verified |
| Severity | High |
| Affected surface | Catalog table metadata, lineage, and DataHub-backed governance |
| Implementation issue | oqullus #529 |
| Code-change repository | sparqd/oqullus |
Where the problem appears
Open a table with known DataHub metadata and lineage, then compare the identities used by the detail and lineage views.
Concrete observed case
Metadata addresses the table as a Trino dataset with catalog.schema.table qualification, while lineage constructs a Hive dataset identity without the catalog. The two views can therefore ask DataHub about different entities for the same selected table.
Expected condition
Derive one canonical DataHub URN from the selected catalog-qualified object and workspace fabric. Reuse it for details, schema, tags, description, lineage, and audit.
Cause and evidence
- Metadata and lineage paths construct different platform and qualified-name identities.
- Catalog selection contains enough information to preserve catalog qualification.
- DataHub treats those URNs as distinct entities rather than aliases.
Why it matters
Lineage or metadata may appear missing, attach to the wrong entity, or allow governance actions against a different object than the one queried.
Existing controls and workarounds
Inspect the canonical entity directly in DataHub and compare the full URN. Do not assume empty Catalog lineage means no lineage exists.
Alternatives considered
- Recommended: one shared canonical identity resolver at the product boundary.
- Create aliases between mismatched URNs — useful for migration but not a substitute for correct identity.
- Continue per-feature URN construction — rejected because drift remains likely.
Component involvement
- Oqullus preserves the selected catalog-qualified identity.
- BFF accepts and validates canonical resource identity.
- DataHub remains the metadata and lineage authority.
Reproduction and verification
Follow CAT-S005. Record the visible state, request outcome, effective identity, and recovery behavior relevant to this finding.
Resolution conditions
Close when every DataHub-backed action for one selected object uses the same URN and verified metadata and lineage appear together for representative fixtures.
Validation and blockers
Oqullus and DataHub integration owners must validate identity mapping and migration of any duplicate entities.