Skip to content

fix(backups): always reset the connectivity flag after a replica backup#1642

Draft
marceloneppel wants to merge 1 commit into
mainfrom
feature/validate-issue-1839
Draft

fix(backups): always reset the connectivity flag after a replica backup#1642
marceloneppel wants to merge 1 commit into
mainfrom
feature/validate-issue-1839

Conversation

@marceloneppel

Copy link
Copy Markdown
Member

Issue

A replica backup disables external connectivity by writing the unit peer databag connectivity flag to "off". The flag was only reset to "on" after the backup run via a fall-through if disabled_connectivity:, reachable only on the success and ExecError paths. A different exception in the backup run — or an action interruption/restart — left the flag stuck "off". Because the flag lives in the unit peer databag it survives restarts and upgrades, leaving pg_hba rejecting peer/replica connections indefinitely (the cluster can no longer talk to itself).

Solution

  • Move the reset into a finally block so it runs regardless of which exception (or none) the backup run raises.
  • Recover deployments already stuck with a stale "off" by resetting it in _on_postgresql_pebble_ready and _on_config_changed, guarded by the cluster-wide is_creating_backup signal so a genuinely in-progress backup is not un-hidden mid-run.

Unit tests cover the exception-path reset and the stale-flag recovery helper.

Checklist

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

@github-actions github-actions Bot added the Libraries: Out of sync The charm libs used are out-of-sync label Jul 9, 2026
@marceloneppel marceloneppel force-pushed the feature/validate-issue-1839 branch 2 times, most recently from 606a252 to 0d693d7 Compare July 9, 2026 15:43
@marceloneppel marceloneppel added the bug Something isn't working as expected label Jul 9, 2026
A replica backup disables external connectivity by writing the unit peer
databag "connectivity" flag to "off". The flag was only reset to "on"
after the backup run via a fall-through `if disabled_connectivity:`,
reachable only on the success and ExecError paths. A different exception
in the backup run — or an action interruption/restart — left the flag
stuck "off". Because the flag lives in the unit peer databag it survives
restarts and upgrades, leaving pg_hba rejecting peer/replica connections
indefinitely (the cluster can no longer talk to itself).

Move the reset into a `finally` block so it runs regardless of which
exception (or none) the backup run raises. Also recover deployments
already stuck with a stale "off" by resetting it in
_on_postgresql_pebble_ready and _on_config_changed, guarded by the
cluster-wide is_creating_backup signal so a genuinely in-progress backup
is not un-hidden mid-run.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel marceloneppel force-pushed the feature/validate-issue-1839 branch from 0d693d7 to 65745ea Compare July 9, 2026 20:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working as expected Libraries: Out of sync The charm libs used are out-of-sync

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant