MINOR - Prepare extra validations for system repository health

[pmbrull]

Describe your changes:

1.11.4 - help us expand the validations

Type of change:

• Bug fix
• Improvement
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

---

Summary by Gitar

• Validation extensibility:
  • Added addExtraValidations() hook in SystemRepository.java for subclasses to add custom health checks
• Schema update:
  • Changed validationResponse.json to allow additionalProperties for new validation fields
• Docker cleanup:
  • Removed unused network configuration from docker-compose-fuseki.yml

_{This will update automatically on new commits.}

---

[github-actions]

TypeScript types have been updated based on the JSON schema changes in the PR

[pmbrull]

this change is intended (though not related). Just helps spinning up Fuseki standalone. Otherwise networks were clashing

[gitar-bot]

🔍 CI failure analysis for f29cd1c: Playwright tests failed again with DIFFERENT tests failing on retry, strongly confirming flakiness. The tests are unrelated to PR changes. This has hit the retry limit.

Issue

The playwright-ci-postgresql (6, 6) job failed again on retry with 7 test failures.

Root Cause

Different tests failed on retry, strongly confirming these are flaky E2E tests:

Run 1 Failures	Run 2 Failures (Retry)
Login.spec.ts:155	Lineage.spec.ts:89 (Table)
Glossary.spec.ts:926	AutoPilot.spec.ts:95 (Mysql)
Lineage.spec.ts:89 (Topic)	Lineage.spec.ts:89 (ApiEndpoint)
Lineage.spec.ts:89 (Container)	ServiceEntity.spec.ts:105 (SearchIndex)
ServiceEntity.spec.ts:207 (MlModel)	ServiceEntity.spec.ts:156 (Drive)
Tag.spec.ts:471 ✗	Tag.spec.ts:471 ✗
Users.spec.ts:460 ✗	Users.spec.ts:460 ✗

Only 2 tests (Tag & Users) failed consistently across both runs. The different failures between runs is a classic flakiness pattern.

Details

This PR only modifies system validation files (validationResponse.json, SystemRepository.java, docker-compose-fuseki.yml) which have no relation to the Lineage, AutoPilot, ServiceEntity, Tag, or Users UI functionality being tested.

Status

This job has now been retried once (max retry limit reached per Flaky Test Retry rule). The persistent failures in Tag.spec.ts and Users.spec.ts may indicate a real issue in those specific tests that needs investigation by the test maintainers, but it is not caused by this PR.

Code Review 👍 Approved with suggestions

Reasonable extensibility changes with one minor type safety concern around allowing arbitrary properties.

Suggestions 💡 1 suggestion

Code Quality: Schema change allows arbitrary properties, reducing type safety

📄 openmetadata-spec/src/main/resources/json/schema/system/validationResponse.json:56

Changing additionalProperties from false to true opens the schema to accept any arbitrary properties without validation. While this provides flexibility for extensibility (matching the new addExtraValidations hook), it reduces type safety and schema enforcement.

Impact:

• Any property can now be added to the validation response without being validated against a schema
• This could lead to inconsistent data structures across different implementations
• The corresponding TypeScript change adds [property: string]: any which weakens type checking

Suggestion:
Consider using additionalProperties with a specific schema (e.g., "additionalProperties": {"$ref": "#/definitions/stepValidation"}) to maintain some level of type safety while still allowing extensibility. Alternatively, if specific extra validations are known, define them explicitly in the schema.

Recommendations

• Consider constraining additionalProperties to a specific type (like stepValidation) rather than allowing any arbitrary properties, to maintain schema validation benefits while still supporting extensibility.

The changes appear to be setting up an extension point for custom validations, which is a valid architectural pattern. The docker-compose network cleanup looks like straightforward maintenance.

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.
✅ Code review is on Gitar will review this change.
Display: compact Hiding non-applicable rules.

Comment with these commands to change:

Auto-apply	✅ Code review	Compact
gitar auto-apply:on	gitar code-review:off	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | This comment will update automatically (Docs)}

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	64.12% (50631/78958)	41.6% (24565/59051)	45.13% (7758/17190)

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

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

[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

[github-actions]

Changes have been cherry-picked to the 1.11.4 branch.