Skip to content

fix: drop removed modules from backup schedules - #1265

Open
DavidePrincipi wants to merge 2 commits into
mainfrom
bug-8094
Open

fix: drop removed modules from backup schedules#1265
DavidePrincipi wants to merge 2 commits into
mainfrom
bug-8094

Conversation

@DavidePrincipi

@DavidePrincipi DavidePrincipi commented Jul 31, 2026

Copy link
Copy Markdown
Member

Summary

  • Removed app instances used to keep lingering in a backup schedule's instances list and in per-node backup_status entries, so list-backups (and the UI) kept reporting them as backed up after the instance was uninstalled.
  • Purge the module id from cluster/backup/* and backup_status when a module or a whole node is removed, and skip any still-stale reference in list-backups by checking cluster/module_uuid.
  • Add a one-time-per-install, idempotent migration that prunes pre-existing dangling references (from before this fix) using cluster/module_node as the authoritative source of live module ids, and restores the cluster/module_uuid invariant that list-backups now relies on.

NethServer/dev#8094

Test plan

  • Create a backup schedule including two app instances, run it
  • Remove one of the instances from the cluster
  • Verify list-backups / the Backup UI no longer shows the removed instance
  • Remove a whole node with backed-up instances and verify the same
  • On a cluster with pre-existing dangling backup references, run a core update and verify the migration cleans them up

Removed app instances kept lingering in a backup schedule's
"instances" list and in per-node backup_status entries, so
list-backups (and the UI) went on reporting them as backed up.

Purge the module id from cluster/backup/* and backup_status when a
module or a whole node is removed, and skip any still-stale
reference in list-backups by checking cluster/module_uuid.

No cluster/event/backup-schedule-changed is published for this
cleanup: the frontend never subscribes to that event, and the
node-side subscribers (backup timer restart, stale Prometheus file
purge) only react to a schedule's existence/enabled state, not to
its instances list, which run-backup already reads fresh from Redis
on every run.

Assisted-by: Claude Code:claude-sonnet-5
Modules removed from the cluster before backup schedule cleanup was
implemented (see previous commit) were left dangling in backup
instances, backup status entries and cluster/module_uuid — the
remove-module/remove-node fix only prevents new occurrences.

Add a one-time-per-install, idempotent migration that prunes those
stale references using cluster/module_node as the authoritative
source of live module ids, and restores the cluster/module_uuid
invariant that list-backups now relies on.

Assisted-by: Claude Code:claude-sonnet-5
@DavidePrincipi

Copy link
Copy Markdown
Member Author

Tests are VERIFIED

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant