21a551cd6f
CI / lint (pull_request) Failing after 21s
CI / typecheck (pull_request) Successful in 58s
CI / security (pull_request) Successful in 52s
CI / quality (pull_request) Successful in 36s
CI / coverage (pull_request) Has been skipped
CI / build (pull_request) Successful in 20s
CI / helm (pull_request) Successful in 23s
CI / unit_tests (pull_request) Successful in 7m5s
CI / docker (pull_request) Has been skipped
CI / e2e_tests (pull_request) Successful in 17m36s
CI / integration_tests (pull_request) Successful in 23m17s
CI / status-check (pull_request) Failing after 1s
CI / benchmark-publish (pull_request) Has been skipped
CI / benchmark-regression (pull_request) Has been skipped
Replace the name-based heuristic ("/" not in name) in db_to_spec() with
the authoritative namespace column check (str(raw_ns) == "builtin"),
consistent with the existing _load_type_registry() implementation.
The old heuristic would misclassify custom resource types whose names
contain no "/" as built-in, potentially blocking their removal via
remove_type(). The namespace column is set to "builtin" by spec_to_db()
for all built-in types and to the actual namespace prefix for custom types,
making it the correct source of truth.
A name-heuristic fallback is retained for legacy rows where the namespace
column is NULL (e.g. rows inserted directly without going through
spec_to_db()).
New BDD scenarios added to resource_registry_service_coverage.feature:
- _db_to_spec sets built_in True when namespace column is "builtin"
- _db_to_spec sets built_in False when namespace column is not "builtin"
ISSUES CLOSED: #3013
72 lines
4.0 KiB
Gherkin
72 lines
4.0 KiB
Gherkin
Feature: Resource registry service coverage gaps
|
|
Cover exception-handling rollback paths and auto_discovery/equivalence
|
|
serialisation round-trips in ResourceRegistryService, _spec_to_db, and
|
|
_db_to_spec.
|
|
|
|
# ── Exception rollback paths ──────────────────────────────────────
|
|
|
|
Scenario: bootstrap_builtin_types rolls back on unexpected exception
|
|
Given a resource registry service with a faulty session for bootstrap
|
|
When I call bootstrap_builtin_types and it fails
|
|
Then the faulty session should have been rolled back
|
|
And the original exception should propagate from bootstrap
|
|
|
|
Scenario: register_type rolls back on non-ValidationError exception
|
|
Given a resource registry service with a faulty session for register_type
|
|
And a temporary valid resource type YAML file exists
|
|
When I call register_type and a non-validation exception occurs
|
|
Then the register_type faulty session should have been rolled back
|
|
And the original non-validation exception should propagate from register_type
|
|
|
|
Scenario: register_resource rolls back on generic exception
|
|
Given a resource registry service with a faulty session for register_resource
|
|
When I call register_resource and a generic exception occurs
|
|
Then the register_resource faulty session should have been rolled back
|
|
And the original generic exception should propagate from register_resource
|
|
|
|
# ── _spec_to_db auto_discovery and equivalence ────────────────────
|
|
|
|
Scenario: _spec_to_db serialises auto_discovery to JSON
|
|
Given a ResourceTypeSpec with auto_discovery set
|
|
When I convert the spec to a database model via _spec_to_db
|
|
Then the database model auto_discover_json should contain the auto_discovery data
|
|
|
|
Scenario: _spec_to_db serialises equivalence to JSON
|
|
Given a ResourceTypeSpec with equivalence set
|
|
When I convert the equivalence spec to a database model via _spec_to_db
|
|
Then the database model equivalence_json should contain the equivalence data
|
|
|
|
# ── _db_to_spec auto_discovery and equivalence ────────────────────
|
|
|
|
Scenario: _db_to_spec parses auto_discover_json from a database row
|
|
Given an in-memory database with a resource type row containing auto_discover_json
|
|
When I convert the database row back to a spec via _db_to_spec
|
|
Then the resulting spec auto_discovery should match the original data
|
|
|
|
Scenario: _db_to_spec parses equivalence_json from a database row
|
|
Given an in-memory database with a resource type row containing equivalence_json
|
|
When I convert the equivalence database row back to a spec via _db_to_spec
|
|
Then the resulting spec equivalence should match the original equivalence data
|
|
|
|
# ── Round-trip through real DB ────────────────────────────────────
|
|
|
|
Scenario: auto_discovery and equivalence survive a full register-and-show round-trip
|
|
Given a real in-memory resource registry service is initialised
|
|
And a YAML config with auto_discovery and equivalence fields exists
|
|
When I register the type with auto_discovery and equivalence via the service
|
|
And I show the registered type with auto_discovery and equivalence
|
|
Then the shown type should have the correct auto_discovery
|
|
And the shown type should have the correct equivalence
|
|
|
|
# ── _db_to_spec built_in field via namespace column ───────────────
|
|
|
|
Scenario: _db_to_spec sets built_in True when namespace column is "builtin"
|
|
Given a resource type DB row with namespace "builtin" and name "git-checkout"
|
|
When I convert that row to a spec via _db_to_spec
|
|
Then the resulting spec built_in should be True
|
|
|
|
Scenario: _db_to_spec sets built_in False when namespace column is not "builtin"
|
|
Given a resource type DB row with namespace "local" and name "local/mytype"
|
|
When I convert that row to a spec via _db_to_spec
|
|
Then the resulting spec built_in should be False
|