Skip to content

[DPE-10885] test(database): cover the client-relation events handler (7/7) - #222

Draft
marceloneppel wants to merge 6 commits into
test/02-db-manager-lifecyclefrom
test/02-db-events
Draft

[DPE-10885] test(database): cover the client-relation events handler (7/7)#222
marceloneppel wants to merge 6 commits into
test/02-db-manager-lifecyclefrom
test/02-db-events

Conversation

@marceloneppel

@marceloneppel marceloneppel commented Aug 17, 2026

Copy link
Copy Markdown
Member

Issue

Last of the seven. PRs 5 and 6 cover the manager; the events handler's guards, defers and status mapping are still untested.

Solution

The request cases drive a real database_requested by writing to the requirer databag rather than calling the handler directly, so the provider library's own leader gate and diff bookkeeping stay in the path under test.

Covers the happy path end to end, both defer paths (cluster not ready, peers not synced), the three blocking outcomes, the departing-unit flag, the leader and follower relation-broken paths, and the substrate split in the removal guard — K8s settles for a started member where VM also needs a primary. The K8s inline endpoint write is asserted present on K8s and absent on VM.

The PR also carries one fix the port review surfaced: building DatabaseRequest read event.requested_entity_secret_content outside any ModelError guard, so an ungranted cross-model secret crashed the hook where both charms set Missing grant to requested entity secret and recovered on the next relation-changed. The guard now sits at the read itself, and its test drives the real event with the property raising. Landing it here rather than in 4/7 keeps the already-pushed branches below untouched.

The mutation review also found holes in the manager tests from PRs 5 and 6, backfilled here: the published URIs and relation scoping of update_endpoints, the delete path's remove_user_from_databases and secret cleanup, the rel_databases cache key, the custom-username credentials paths, unblock_custom_user_errors, and the literal blocking messages (several tests had asserted constants imported from the module under test, which no test could reword-proof).

Wiring up at:

Checklist

  • I have added or updated any relevant documentation.
  • I have cleaned any remaining cloud resources from my accounts.

Drives real database-requested, relation-departed and relation-broken events
through the handler rather than calling its methods, so the provider library's
own leader gate and diff bookkeeping stay in the path under test.

Covers both substrates' readiness guards, including the K8s removal guard that
settles for a started member where a request also waits on the primary endpoint,
and the K8s inline endpoint write the port kept.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
…andler

The port moved the event.requested_entity_secret_content read out of the
charm's _get_credentials try block into the DatabaseRequest construction,
which left the manager's except ModelError guarding only a plain dict
access it can never see. The vendored property resolves the secret on
access and raises ModelError while a cross-model grant is still pending,
so an ungranted requested-entity secret crashed the hook where the charm
set a Blocked status and recovered on the next relation-changed.

Restore the guard at the access boundary so the handler blocks instead
of raising, matching both charms' 16/edge behavior.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
…_endpoints

The ported test asserted the endpoints and read-only-endpoints values but
never the URIs built from them, so building the read-write URI from the
read-only endpoints survived the whole suite, and the original charm test's
uris assertion was silently dropped in the port. Also restore the two other
dropped scenarios: a relation without credentials publishes nothing, a
prefix with no matching database clears the stale URIs, and a
relation-scoped update leaves the other relations' databags untouched.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The delete test never asserted remove_user_from_databases, which only
fires when the deleted relation's database still lives in another
relation's prefix mapping — the one arrange that reaches the loop, so
dropping the loop survived the suite. Pin it with that arrange, along
with the real secret-removal round trip in oversee_users, the
rel_databases app-data cache key the Patroni pg_hba render reads, and
the literal user-visible blocking messages, which were asserted through
constants imported from the module under test and so could be reworded
freely.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The custom-username happy path in get_credentials — a granted secret
returns its password verbatim, an ungranted one gets a generated
password — was never executed by any test, and unblock_custom_user_errors
had no coverage at all despite being the route update_unit_status takes
for every custom-user blocking status. Cover its three outcomes (clear,
invalid extra user roles elsewhere, forbidden or unreadable custom user)
with literal status text.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
A few of the new assertions and arrange lines landed off the
formatter's preference for line breaks; run it so tox -e lint passes
at the branch tip.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel
marceloneppel force-pushed the test/02-db-manager-lifecycle branch from 9dfff65 to 445b125 Compare August 20, 2026 12:34
@marceloneppel marceloneppel changed the title [DPE-10841] test(database): cover the client-relation events handler (7/7) [DPE-10885] test(database): cover the client-relation events handler (7/7) Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant