Skip to content

Conversation

@pedro93
Copy link
Collaborator

@pedro93 pedro93 commented Jan 10, 2026

Summary

Fixes a bug where updating any setting on a structured property that already has showAsAssetBadge=true would fail with:

Cannot have more than one property set with show as badge. Property urns currently set: [urn:li:structuredProperty:product_type]

The error occurs even though the property being updated IS the one with the badge - no new badge is being added.

Root Cause

ShowPropertyAsBadgeValidator searches for all properties with showAsAssetBadge=true, but never excludes the current entity being updated from the conflict check. So when updating property X which already has the badge, it finds X in the search results and incorrectly treats it as a conflict.

Fix

Filter out the current entity URN from the search results before checking for badge conflicts. Validation now only fails when a different property already has the badge enabled.

Additional Changes

Added PR guidelines section to CLAUDE.md to ensure Claude Code follows the project's PR template when creating pull requests.

Related Issues

  • Fixes CUS-6349
  • Related to CUS-7363 (same underlying bug)

Test Plan

  • Added unit test testValidUpsertWhenUpdatingSamePropertyWithBadge() that verifies updating a property that already has the badge succeeds
  • Existing tests continue to pass (4 tests total)
  • Manual verification: Update any setting on a structured property that has showAsAssetBadge=true enabled

Checklist

  • The PR conforms to DataHub's Contributing Guideline (especially PR Title Format)
  • Links to related issues (if applicable)
  • Tests added/updated (if applicable)
  • Docs added/updated (if applicable)

…ve badge enabled

When updating a structured property that already has showAsAssetBadge=true,
the validation was incorrectly failing with "Cannot have more than one
property set with show as badge" even though the property being updated
was the same one with the badge.

The fix filters out the current entity URN from the badge conflict check,
so validation only fails when a *different* property already has the badge.

Fixes CUS-6349
@alwaysmeticulous
Copy link

alwaysmeticulous bot commented Jan 10, 2026

✅ Meticulous spotted 0 visual differences across 952 screens tested: view results.

Meticulous evaluated ~8 hours of user flows against your PR.

Expected differences? Click here. Last updated for commit e74c1cc. This comment will update as new commits are pushed.

@codecov
Copy link

codecov bot commented Jan 10, 2026

Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
...rties/validation/ShowPropertyAsBadgeValidator.java 77.77% 1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

@datahub-cyborg datahub-cyborg bot added the needs-review Label for PRs that need review from a maintainer. label Jan 10, 2026
Add blank lines before code blocks and lists per Prettier requirements.

Co-Authored-By: Claude Opus 4.5 <[email protected]>
.build();
// Only need to get first set, if there are more then will have to resolve bad state
ScrollResult scrollResult = scrollIterator.next();
if (CollectionUtils.isNotEmpty(scrollResult.getEntities())) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By shifting this you are removing a null check, are you sure this can never be null? Presumably it existed for a reason

if (scrollResult.getEntities().size() > 1) {
// Filter out the current entity being updated - it's allowed to keep its own badge
List<SearchEntity> otherBadgeEntities =
scrollResult.getEntities().stream()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional filtering should occur after verifying that the initial list is not empty or null, no?

@datahub-cyborg datahub-cyborg bot added pending-submitter-response Issue/request has been reviewed but requires a response from the submitter and removed needs-review Label for PRs that need review from a maintainer. labels Jan 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pending-submitter-response Issue/request has been reviewed but requires a response from the submitter product PR or Issue related to the DataHub UI/UX

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants