The oldest config revision is activated when replicating NetBox #20824
Description
NetBox Edition
NetBox Community
NetBox Version
v4.4.6
Python Version
3.11
Steps to Reproduce
- Install new NetBox 4.3.7 ** (
git checkout v4.3.7) server as per official instructions but don't runupgrade.shyet pg_dumpa NetBox 3.7.3 database from an existing NetBox server and import it on the new server- Run
upgrade.sh - See that the
core_configrevisiontable does not yet haveactivecolumn git checkout v4.4.6and runupgrade.sh- See that there is a new
activecolumn in thecore_configrevisiontable - See that the oldest configrevision has
active = true
(** In some experiences, including my own, it is not possible to upgrade a NetBox 3.7.3 database directly to 4.4.x, thus the intermediate upgrade step via 4.3.7.)
Expected Behavior
The newest configuration revision is active when NetBox database is replicated from old version to new version.
Observed Behavior
The oldest configuration revision is active.
This is a major problem because the NetBox background task starts immediately (after starting the new NetBox services) deleting old changelog entries according to the retention time configured in the active config revision. Thus, if/when the oldest config revision has retention time shorter than the latest config revision, old changelogs are unintentionally lost.
Workaround attempt: I set the newest config revision as active=true (required also setting the oldest revision to active=false before that) in the database before starting NetBox services the first time. While it looks like the newest config revision is now active in the UI, the background task still executed the cleanup task with the old settings:
2025-11-18 15:27:48,165 netbox.jobs.SystemHousekeepingJob INFO: Pruning old changelog entries...
2025-11-18 15:27:48,168 netbox.jobs.SystemHousekeepingJob DEBUG: Changelog retention period: 1825 days (2020-11-19 13:27:48)
2025-11-18 15:27:50,020 netbox.jobs.SystemHousekeepingJob INFO: Deleted 221 expired changelog records
(1825 days was set in the oldest config revision, while the newest (now active) revision has 0)
While testing this workaround I observed that some data in Redis also affected this: When I had manually activated the latest config revision in the UI and then deleted, imported and upgraded the database again, the problem did not occur, meaning that the latest config revision was still active (INFO: Pruning old changelog entries..., INFO: No retention period specified; skipping.). But, when I also reinstalled redis-server (when importing the database again), the error occurred. Thus, apparently in-place upgrades work correctly, but not migrations/replications to new servers. Maybe this would be a useful workaround as well: https://stackoverflow.com/questions/6004915/how-do-i-move-a-redis-database-from-one-server-to-another .
Or maybe the workaround currently is to first execute the migration+upgrade steps and activate the latest revision (which deleted unintended changelogs), and then do the steps again on the same server so that the data in Redis database takes care of not using the oldest revision at all.
Another workaround is probably removing all config revisions but the latest one (to prevent the cleanup job runaway with incorrect settings), but that's not ideal as all the config revision history is then lost in the UI.