Migration 0006_tag_object_types fails for open branches when upgrading from v0.6.x to v1.x together with NetBox v4.4+ #705

Plugin Version

v1.1.3, upgrading from v0.6.1 (0006 is identical in v1.2.2)

NetBox Version

v4.5.10, upgrading from v4.3.2

Python Version

3.12

Steps to Reproduce

1. Run NetBox v4.3.x with netbox-branching v0.6.1 (no plugin migrations after 0005_branch_applied_migrations).
2. Create a branch and leave it in the Ready state (not merged or archived).
3. Upgrade NetBox to v4.5.10 and netbox-branching to v1.1.3 in the same step, and run upgrade.sh (manage.py migrate).

Expected Behavior

All migrations apply. The open branch gets its copy of the extras_tag_object_types table and then shows Pending Migrations.

Observed Behavior

NetBox's own migrations apply first, including extras.0131_concrete_objecttype. Then netbox_branching.0006_tag_object_types fails for the open branch:

Applying netbox_branching.0006_tag_object_types...
    Copying extras_tag_object_types for branch <name> (<schema_id>)... Traceback (most recent call last):
  ...
  File ".../netbox_branching/migrations/0006_tag_object_types.py", line 44, in copy_table
    cursor.execute(
  ...
django.db.utils.ProgrammingError: relation "branch_<schema_id>.extras_tag_object_types_objecttype_id_idx" does not exist

Merged and archived branches are skipped (the loop only covers READY), so only installs with an open branch hit this.

Suspected Cause

extras.0131_concrete_objecttype changes Tag.object_types back to contenttypes.ContentType, which renames public.extras_tag_object_types.objecttype_id to contenttype_id. 0006 copies the table with CREATE TABLE ... (LIKE public.extras_tag_object_types INCLUDING INDEXES), so the copied indexes are now named after contenttype_id, and the hard-coded ALTER INDEX ... extras_tag_object_types_objecttype_id_idx RENAME ... doesn't find them. 0006 assumes the NetBox v4.0–v4.3 column name, and nothing makes it run before extras.0131.

Workaround that worked for us: before rerunning migrate, create the table in the branch schema the way 0006 would have on v4.3, so 0006 takes its "Skipping; table already exists" path. In one transaction:

SET LOCAL ROLE netbox;
CREATE TABLE branch_<id>.extras_tag_object_types (LIKE public.extras_tag_object_types INCLUDING INDEXES);
INSERT INTO branch_<id>.extras_tag_object_types SELECT * FROM public.extras_tag_object_types;
ALTER TABLE branch_<id>.extras_tag_object_types ALTER COLUMN id SET DEFAULT nextval('public.extras_tag_object_types_id_seq');
ALTER TABLE branch_<id>.extras_tag_object_types RENAME COLUMN contenttype_id TO objecttype_id;
ALTER INDEX branch_<id>.extras_tag_object_types_contenttype_id_idx RENAME TO extras_tag_object_types_contenttype_id_c1b220c3;
ALTER INDEX branch_<id>.extras_tag_object_types_tag_id_idx RENAME TO extras_tag_object_types_tag_id_2e1aab29;
ALTER INDEX branch_<id>.extras_tag_object_types_tag_id_contenttype_id_key RENAME TO extras_tag_object_types_tag_id_contenttype_id_2ff9910c_uniq;

After that, migrate completed, and the branch's own Migrate job applied extras.0131_concrete_objecttype inside the branch without error. (That branch then failed on dcim.0208 for an unrelated reason in our own history: it was created on NetBox v4.2 and never migrated to v4.3.) Archiving open branches before upgrading also avoids the problem.

Proposed Fix

• In 0006, don't hard-code the index names: read them from pg_indexes after the copy. When the branch schema predates extras.0131 (its applied migrations don't include it), also rename the copied column to objecttype_id, so the branch's own migrate step can apply 0131 later.
• run_before = [('extras', '0131_concrete_objecttype')] on 0006 would fix new upgrades, but would probably raise InconsistentMigrationHistory on installs that have already applied 0131. Untested by us.

Related: #321 (the bug 0006 fixes) and #309. This replaces #704, which was auto-closed because it didn't use the form properly. Sorry, I'm new to filling out bug reports here, but REALLY appreciate the work you're doing!