Differentiate rule violation errors from server errors in UI

[pmbrull]

Summary

• Rule violations (HTTP 400 from RuleValidationException) and server errors (HTTP 500) were showing the same red error banner, making it impossible for users to distinguish between validation issues they need to fix and actual system failures
• Backend: Added specific RuleValidationException handling in CatalogGenericExceptionMapper to return responses with errorType: "RULE_VIOLATION" using the existing SDK ErrorMessage format
• Frontend: showErrorToast now detects the RULE_VIOLATION error type and displays rule violations as warning toasts (orange/yellow) instead of error toasts (red), with auto-close after 5 seconds

Closes https://github.com/open-metadata/openmetadata-collate/issues/2382

Test plan

• Create/update an entity that violates a governance rule (e.g., multiple team ownership) and verify a warning banner (orange) appears instead of an error banner (red)
• Trigger an actual server error (e.g., invalid request body) and verify the error banner (red) still appears as before
• Verify warning banners auto-close after 5 seconds while error banners persist
• Run backend integration tests for RuleEngineTests to verify existing assertions still pass with the updated response format

[gitar-bot]

💡 Quality: alertType inferred as string instead of AlertBarProps['type']

The ternary const alertType = isRuleViolation ? 'warning' : 'error' is inferred as string by TypeScript. The addAlert method expects AlertProps['type'] (which is 'success' | 'info' | 'warning' | 'error' | undefined). While this works at runtime, it bypasses type checking — if someone later changes one of the string literals to a typo, the compiler won't catch it.

Adding a type annotation makes the intent explicit and enables compile-time safety:

const alertType: AlertBarProps['type'] = isRuleViolation ? 'warning' : 'error';

This is a minor improvement — TypeScript will likely narrow the type correctly from the string literals in practice.

Suggested fix:

const alertType: AlertBarProps['type'] = isRuleViolation ? 'warning' : 'error';

_{Was this helpful? React with 👍 / 👎}

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	65.86% (56849/86322)	45.38% (29850/65780)	48.05% (8966/18659)

[gitar-bot]

🔍 CI failure analysis for 1bee612: Maven SonarCloud CI failed with 50 test failures unrelated to PR changes - issues from main branch merge including API service deserialization problems, S3/storage failures, and JSON serialization changes.

Issue: Maven SonarCloud CI - 50 Test Failures

The maven-sonarcloud-ci job failed with 50 test failures out of 7,978 tests. These failures appear to be from the main branch merge (commit 1bee612), not from this PR's changes.

Failure Categories

1. API Service Connection Deserialization (~40+ failures)

• Test: APIServiceResourceTest (multiple methods)
• Error: Connection object deserialized as Map instead of OpenAPISchemaURL object:

expected: <OpenAPISchemaURL@...[openAPISchemaURL=http://localhost:8585/swagger.json]>
but was: <{openAPISchemaURL=http://localhost:8585/swagger.json}>

• Cause: Pydantic/Jackson deserialization issue from recent schema changes in main

2. Ingestion Pipeline Log Storage (~4 failures)

• Test: IngestionPipelineLogStorageTest
• Errors: S3 multipart upload failures, missing objects, stream closure errors
• Cause: S3 mock/integration infrastructure issues

3. JSON Serialization Change (1 failure)

• Test: JsonUtilsTest.java:152
• Error: Unexpected entityStatus: "Unprocessed" field in JSON output
• Cause: New field added, likely from PR feat: extract core-component changes from PR #26064 (Skeleton + Tooltip updates) #26147 merged from main

4. OpenSearch Container Startup (1 failure)

• Test: OpenSearchConfigurationTest
• Error: Container startup failed for opensearchproject/opensearch:3.4.0

5. S3 Storage Key Issues (1+ failure)

• Test: IngestionPipelineLogStreamingTest
• Error: "The specified key does not exist"

Relevance to This PR

UNRELATED - This PR only modifies:

• Exception mapper to add errorType: "RULE_VIOLATION"
• Toast utilities to display rule violations as warnings

None of the 50 failing tests interact with exception handling or toast display logic.

Recent Main Branch Changes (commit 1bee612 merge)

• PR feat: extract core-component changes from PR #26064 (Skeleton + Tooltip updates) #26147: Extract core-component changes
• PR Fix #23101: Persona derived via teams #26052: Persona derived via teams
• PR Fix #25815: Fix Kafka Debug Logs #25816: Fix Kafka Debug Logs

---

Assessment

These are pre-existing test failures from main branch, not regressions from this PR. The Test Report job failure is cascading.

Recommendation

Check if main branch has these same failures. Consider waiting for main branch fixes before merging.

Code Review ✅ Approved 1 resolved / 1 findings

Clean, well-structured PR that correctly differentiates rule violations from server errors. The exception handling order is correct (RuleValidationException before IllegalArgumentException), the frontend detection logic gracefully falls back to error toasts, and the auto-close behavior is properly handled by the alert store's built-in defaults.

✅ 1 resolved

✅ Quality: alertType inferred as string instead of AlertBarProps['type']

📄 openmetadata-ui/src/main/resources/ui/src/utils/ToastUtils.ts:134
The ternary const alertType = isRuleViolation ? 'warning' : 'error' is inferred as string by TypeScript. The addAlert method expects AlertProps['type'] (which is 'success' | 'info' | 'warning' | 'error' | undefined). While this works at runtime, it bypasses type checking — if someone later changes one of the string literals to a typo, the compiler won't catch it.

Adding a type annotation makes the intent explicit and enables compile-time safety:

const alertType: AlertBarProps['type'] = isRuleViolation ? 'warning' : 'error';

This is a minor improvement — TypeScript will likely narrow the type correctly from the string literals in practice.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ingestion'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud