A process that has loaded a type created in an unmerged branch can no longer provision branches: CREATE TABLE … LIKE public.custom_objects_N fails with 'relation does not exist' #1045

Plugin Version

1.0.0 (also reproduced on main at b34ee80)

NetBox Version

4.7.4 with netbox-branching 1.2.3 (also reproduced with netbox-branching main at 5f72279)

Python Version

3.12

Steps to Reproduce

1. Create branch A and activate it.
2. In branch A, create a Custom Object Type widget with a text field name. Do not merge.
3. In the same process, create branch B and provision it.

The process that matters is the one that runs the provisioning job. It fails as soon as it has resolved widget's dynamic model for any reason. Two ways to get there that don't need a shell:

• Branch A's merge fails (for example because main already has a type with the same name), so the rq worker that ran the merge now has the model registered. Every later provisioning job on that worker fails, even after branch A is deleted.
• A worker runs any job that touches a widget in branch A (search indexing, reindex, webhooks), then picks up a provisioning job.

Minimal shell version (one process):

with activate_branch(a), event_tracking(request):
    CustomObjectType.objects.create(name='widget', slug='widget')     # in branch A
Branch(name='b').save(provision=False); b.provision(user=user)       # same process

Expected Behavior

Branch B provisions. The type created in branch A has no table in main yet, so it should not be part of the set of tables replicated into B.

Observed Behavior

Provisioning of B fails and the branch is left in the failed state:

django.db.utils.ProgrammingError: relation "public.custom_objects_150" does not exist
LINE 1: ...BLE "branch_ba0tjlii"."custom_objects_150" ( LIKE "public"."custom_objects_150" INCLUDING GENERATED )
  File "netbox_branching/models/branches.py", line 1410, in provision   (netbox-branching main; 1.2.3 fails at the same CREATE TABLE … LIKE in provisioning.py)

Every further provision in that process fails the same way until the process is restarted. A fresh process provisions fine, because ContentType.model_class() returns None there and netbox-branching skips the entry; it starts failing as soon as it, too, resolves the branch's type (verified: fresh process provisions OK, then serves one object create in branch A, then its next provision fails).

Related observations from the same runs:

• A failed merge of branch A (duplicate type name) followed by deleting branch A does not clear the condition in that process.
• Deleting branch A leaves a django_content_type / core_objecttype row for table150model in main with no CustomObjectType behind it.

Suspected Cause

custom_object_type_post_save_handler creates the type's ObjectType in main at creation time, also when the type is created inside a branch (core_objecttype / django_content_type are not branched), and the ObjectType carries the branching feature.

netbox_branching.utilities.get_tables_to_replicate() builds the replication list from ObjectType.objects.with_feature('branching') and model_class(). Model registration in apps.all_models is process-global; once Table150Model has been built in a process for branch A, model_class() resolves it in main context as well, and its db_table is added to the list although the table only exists in branch A's schema. CREATE TABLE … LIKE public.custom_objects_150 then fails.

Proposed Fix

Any of:

1. In CustomObjectsPluginConfig.get_model() (the path ContentType.model_class() takes), return None when no active branch is set and the CustomObjectType row does not exist in main. That matches what a fresh process already does.
2. Have the Custom Objects branching resolver exclude types whose table is absent from public from the replicated set, or have get_tables_to_replicate() check to_regclass(main_schema.table) before adding a dynamic model's table.
3. Remove the tableNmodel ContentType / ObjectType row when a branch that created the type is deleted without merging (separate, smaller clean-up).