Affected module
Other
Describe the bug
After upgrading OpenMetadata to 2.0.0, the application starts successfully, but the FrameworkSeedLoader logs multiple warnings and PostgreSQL exceptions while loading the built-in AI Governance frameworks.
The loader attempts to insert AI Governance framework controls that already exist in ai_framework_control_entity.
PostgreSQL rejects the inserts because the existing controls have the same fqnhash:
ERROR: duplicate key value violates unique constraint
"ai_framework_control_entity_fqnhash_key"
This happens for several built-in AI Governance frameworks, not just one.
Environment
OpenMetadata version: 2.0.0
Database: PostgreSQL
Search backend: OpenSearch
Deployment: Kubernetes
Java: 21
The upgrade migration to 2.0.0 is registered as applied by:
./bootstrap/openmetadata-ops.sh info
The output contains:
| 2.0.0 | 2026-08-26 10:46:44.531417 | ... |
Actual behavior
During startup, FrameworkSeedLoader tries to create controls that are already present in the database.
Example for Canada AIDA:
WARN FrameworkSeedLoader - Failed to load framework seed
json/data/aiGovernance/frameworks/canada_aida.json:
org.postgresql.util.PSQLException:
ERROR: duplicate key value violates unique constraint
"ai_framework_control_entity_fqnhash_key"
Detail:
Key (fqnhash)=(803a7d74349115176693366aa97d4405) already exists.
The attempted entity is:
{
"name": "aida-1",
"fullyQualifiedName": "aida-1",
"displayName": "High-impact System Designation",
"framework": {
"name": "canada_aida"
}
}
The existing PostgreSQL row has the same logical entity:
name: aida-1
fqnhash: 803a7d74349115176693366aa97d4405
framework: canada_aida
but a different UUID.
The same issue occurs for multiple built-in frameworks:
canada_aida.json
singapore_mgf.json
nist_ai_rmf.json
eu_ai_act.json
us_bill_of_rights.json
iso_iec_42001.json
china_ai.json
uk_ai_regulation.json
soc2_ai.json
Examples include:
canada_aida
aida-1
fqnhash=803a7d74349115176693366aa97d4405
singapore_mgf
mgf-1
fqnhash=371ca796b58a8b98a42e4505d6377922
nist_ai_rmf
govern
fqnhash=564afb427cb3571f2af0285572efecf8
eu_ai_act
art-5
fqnhash=a53ba5e934b3ab1b5daa10280507f698
us_bill_of_rights
bor-safe
fqnhash=d04ac17ccb2f770ae1f9180e266ccdc1
iso_iec_42001
clause-4
fqnhash=926d4da78a52bf852785407010faca02
china_ai
cn-1
fqnhash=72e479ec1a262b1fe7b9592e0996e09f
uk_ai_regulation
uk-1
fqnhash=b32c736dc2f7667d08a8c669f52af24d
The stack trace shows the insert originating from:
AIFrameworkControlRepository.storeEntity()
EntityRepository.createNewEntity()
EntityRepository.create()
FrameworkSeedLoader.seedBundle()
FrameworkSeedLoader.loadFromResources()
AIGovernanceFrameworkResource.initialize()
The SQL operation is an unconditional insert:
INSERT INTO ai_framework_control_entity (fqnHash, json)
VALUES (:nameHashColumnValue, :json :: jsonb)
To Reproduce
Have an OpenMetadata database containing the AI Governance framework seeds.
Upgrade/start OpenMetadata 2.0.0.
Observe the application startup logs.
FrameworkSeedLoader attempts to insert existing AI framework controls.
PostgreSQL returns:
duplicate key value violates unique constraint
"ai_framework_control_entity_fqnhash_key"
Restart OpenMetadata and observe the same seed-loading errors again.
Expected behavior
Expected behavior
Loading the built-in AI Governance seeds should be idempotent.
If a framework/control already exists, FrameworkSeedLoader should detect it by FQN / fqnhash and either:
reuse the existing entity,
update it when required, or
skip it when the seed has already been loaded.
Restarting OpenMetadata, or upgrading an installation where these entities already exist, should not generate PostgreSQL unique-constraint violations.
Observed behavior
FrameworkSeedLoader appears to generate a new UUID and call the entity creation path even though an entity with the same FQN / fqnhash already exists.
Conceptually the current behavior seems to be:
load seed
|
generate new entity UUID
|
create()
|
INSERT
|
same FQN -> same fqnhash
|
UNIQUE constraint violation
The expected behavior would be closer to:
load seed
|
lookup entity by FQN/fqnhash
|
+-- exists --> reuse/update/skip
|
+-- missing --> create
Before calling EntityRepository.create(...), FrameworkSeedLoader could check whether the framework/control already exists by fullyQualifiedName / fqnhash.
Alternatively, the seed loading logic could use an idempotent create-or-update/upsert path rather than unconditional entity creation.
OS
kubernetes
Python version
No response
OpenMetadata version
2.0.0
OpenMetadata Ingestion package version
No response
Additional context
The existing rows do not appear corrupted. For example, the existing aida-1 row contains the expected framework, description, category and evidence requirements.
The issue is also reproducible across multiple different built-in framework seeds, which suggests this is not an isolated hash collision.
Despite the warnings, OpenMetadata continues starting successfully and registers the AI Governance resources, so this appears to be a seed initialization/idempotency problem rather than a fatal database migration failure.
openmetadata-ops.sh info also shows the 2.0.0 migration as successfully applied.
Pre-submission checklist
Affected module
Other
Describe the bug
After upgrading OpenMetadata to 2.0.0, the application starts successfully, but the FrameworkSeedLoader logs multiple warnings and PostgreSQL exceptions while loading the built-in AI Governance frameworks.
The loader attempts to insert AI Governance framework controls that already exist in ai_framework_control_entity.
PostgreSQL rejects the inserts because the existing controls have the same fqnhash:
ERROR: duplicate key value violates unique constraint
"ai_framework_control_entity_fqnhash_key"
This happens for several built-in AI Governance frameworks, not just one.
Environment
OpenMetadata version: 2.0.0
Database: PostgreSQL
Search backend: OpenSearch
Deployment: Kubernetes
Java: 21
The upgrade migration to 2.0.0 is registered as applied by:
./bootstrap/openmetadata-ops.sh info
The output contains:
| 2.0.0 | 2026-08-26 10:46:44.531417 | ... |
Actual behavior
During startup, FrameworkSeedLoader tries to create controls that are already present in the database.
Example for Canada AIDA:
WARN FrameworkSeedLoader - Failed to load framework seed
json/data/aiGovernance/frameworks/canada_aida.json:
org.postgresql.util.PSQLException:
ERROR: duplicate key value violates unique constraint
"ai_framework_control_entity_fqnhash_key"
Detail:
Key (fqnhash)=(803a7d74349115176693366aa97d4405) already exists.
The attempted entity is:
{
"name": "aida-1",
"fullyQualifiedName": "aida-1",
"displayName": "High-impact System Designation",
"framework": {
"name": "canada_aida"
}
}
The existing PostgreSQL row has the same logical entity:
name: aida-1
fqnhash: 803a7d74349115176693366aa97d4405
framework: canada_aida
but a different UUID.
The same issue occurs for multiple built-in frameworks:
canada_aida.json
singapore_mgf.json
nist_ai_rmf.json
eu_ai_act.json
us_bill_of_rights.json
iso_iec_42001.json
china_ai.json
uk_ai_regulation.json
soc2_ai.json
Examples include:
canada_aida
aida-1
fqnhash=803a7d74349115176693366aa97d4405
singapore_mgf
mgf-1
fqnhash=371ca796b58a8b98a42e4505d6377922
nist_ai_rmf
govern
fqnhash=564afb427cb3571f2af0285572efecf8
eu_ai_act
art-5
fqnhash=a53ba5e934b3ab1b5daa10280507f698
us_bill_of_rights
bor-safe
fqnhash=d04ac17ccb2f770ae1f9180e266ccdc1
iso_iec_42001
clause-4
fqnhash=926d4da78a52bf852785407010faca02
china_ai
cn-1
fqnhash=72e479ec1a262b1fe7b9592e0996e09f
uk_ai_regulation
uk-1
fqnhash=b32c736dc2f7667d08a8c669f52af24d
The stack trace shows the insert originating from:
AIFrameworkControlRepository.storeEntity()
EntityRepository.createNewEntity()
EntityRepository.create()
FrameworkSeedLoader.seedBundle()
FrameworkSeedLoader.loadFromResources()
AIGovernanceFrameworkResource.initialize()
The SQL operation is an unconditional insert:
INSERT INTO ai_framework_control_entity (fqnHash, json)
VALUES (:nameHashColumnValue, :json :: jsonb)
To Reproduce
Have an OpenMetadata database containing the AI Governance framework seeds.
Upgrade/start OpenMetadata 2.0.0.
Observe the application startup logs.
FrameworkSeedLoader attempts to insert existing AI framework controls.
PostgreSQL returns:
duplicate key value violates unique constraint
"ai_framework_control_entity_fqnhash_key"
Restart OpenMetadata and observe the same seed-loading errors again.
Expected behavior
Expected behavior
Loading the built-in AI Governance seeds should be idempotent.
If a framework/control already exists, FrameworkSeedLoader should detect it by FQN / fqnhash and either:
reuse the existing entity,
update it when required, or
skip it when the seed has already been loaded.
Restarting OpenMetadata, or upgrading an installation where these entities already exist, should not generate PostgreSQL unique-constraint violations.
Observed behavior
FrameworkSeedLoader appears to generate a new UUID and call the entity creation path even though an entity with the same FQN / fqnhash already exists.
Conceptually the current behavior seems to be:
load seed
|
generate new entity UUID
|
create()
|
INSERT
|
same FQN -> same fqnhash
|
UNIQUE constraint violation
The expected behavior would be closer to:
load seed
|
lookup entity by FQN/fqnhash
|
+-- exists --> reuse/update/skip
|
+-- missing --> create
Before calling EntityRepository.create(...), FrameworkSeedLoader could check whether the framework/control already exists by fullyQualifiedName / fqnhash.
Alternatively, the seed loading logic could use an idempotent create-or-update/upsert path rather than unconditional entity creation.
OS
kubernetes
Python version
No response
OpenMetadata version
2.0.0
OpenMetadata Ingestion package version
No response
Additional context
The existing rows do not appear corrupted. For example, the existing aida-1 row contains the expected framework, description, category and evidence requirements.
The issue is also reproducible across multiple different built-in framework seeds, which suggests this is not an isolated hash collision.
Despite the warnings, OpenMetadata continues starting successfully and registers the AI Governance resources, so this appears to be a seed initialization/idempotency problem rather than a fatal database migration failure.
openmetadata-ops.sh info also shows the 2.0.0 migration as successfully applied.
Pre-submission checklist