Soda Quality Check Duplication in DataHub UI When Adding or Renaming Check Names – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: Soda Integration / Assertion Identity

Issue

When a name is added to an existing Soda quality check — or an existing check name is changed — a duplicate assertion appears in the DataHub UI Quality Summary view. The original (unnamed or differently-named) assertion remains visible alongside the newly named one, and the run history associated with the original assertion does not carry over to the new entry. This occurs because Soda computes an internal identity hash for each check based on its configuration (including its name), and DataHub derives the assertion URN from that identity. Any change to the check name regenerates the identity hash, producing a new URN that DataHub treats as an entirely separate assertion entity.

Error Messages

No error is thrown — the duplication appears silently as two separate assertion entries in the Quality Summary UI.

You Might Be Asking

Why did adding a display name to my Soda check create a duplicate assertion in DataHub?
Can I merge or link the old assertion history to the new (renamed) check?
How do I prevent Soda check renames from creating new assertions in DataHub?
How do I clean up orphaned or duplicate assertions in the DataHub Quality Summary view?

Solution

Understand the root cause.
DataHub identifies each assertion by a URN of the form urn:li:assertion:<md5-hash>. When no explicit stable ID is set on a Soda check, Soda includes the check's name (and other configuration fields) in its internal identity hash. DataHub derives its assertion URN from that hash. The result is:
- Before renaming: URN is hashed from {dataset, check_type, original_name_or_fallback, ...}
- After renaming: URN is hashed from {dataset, check_type, new_name, ...}
Because the hash changes, DataHub creates a new assertion entity. The old one is not deleted automatically — it becomes an orphaned (stale) assertion, which is why both appear in the UI.
Understand the history limitation.
There is currently no built-in mechanism in DataHub to merge assertion run history from one URN to another. Historical results attached to the old URN cannot be automatically transferred to the new URN. This is a product design characteristic, not a bug or regression.
(Short-term workaround) Revert the name change.
If preserving historical continuity is critical and the rename has not yet been broadly deployed, reverting the Soda check back to its original unnamed or previously-named state will restore the original URN and its associated run history in the DataHub UI.
(Recommended — going forward) Pin a stable identity on each Soda check before adding a display name.
Soda supports an explicit identity (or id) field on check definitions. When this field is present, Soda anchors its identity hash to that value rather than to the check's name. This means you can freely add, change, or remove the display name without altering the identity hash or the resulting DataHub assertion URN.

Set the identity field before you add or change a display name. Example Soda check definition with a stable identity:
```
# checks.yml

checks for your_schema.your_table:
  - row_count > 0:
      identity: stable-check-id-001        # Anchors the URN — never change this value
      name: Table is not empty             # Display name — can be changed freely once identity is set
```
Important: Once you set an identity value and it has been ingested into DataHub, do not change the identity value itself. Only the name (display name) field should be modified going forward.
Clean up orphaned (stale) assertions.
After stabilizing your checks using the identity field, the old assertions that were created before the stable ID was set will remain as orphaned entities in DataHub. Remove them using one of the following methods:
- Via the DataHub CLI (soft delete):
```
datahub delete --urn "urn:li:assertion:<old-assertion-hash>"
```
  Replace <old-assertion-hash> with the actual MD5 hash portion of the orphaned assertion's URN. You can find the URN by navigating to the assertion in the DataHub UI and inspecting the URL or entity details.
- Via the DataHub UI (hard delete):
  Navigate to the orphaned assertion on the Quality Summary page, open its options menu (three-dot / kebab menu), and select Delete. Note that a hard delete via the UI is permanent and cannot be undone.

Additional Notes

This behavior applies whenever the Soda-to-DataHub integration computes assertion URNs from Soda's internal identity hash, which by default incorporates the check name and other configuration fields. The behavior is consistent across DataHub's assertion identity model (AssertionInfo, CustomAssertionInfo) and is not specific to a particular DataHub version. The identity field in Soda check definitions is a Soda-side feature; refer to the Soda documentation for the exact field name supported by your version of Soda Core (identity or id depending on the Soda version in use). Changes made via the DataHub API that alter assertion-identifying fields have the same effect as changes made in the Soda YAML configuration — both cause URN regeneration if no stable identity is pinned.

Issue

Error Messages

You Might Be Asking

Solution

Additional Notes

Related Documentation