Skip to content

Conversation

jnovinger
Copy link
Member

Fixes: #20290

In v4.4.0, ObjectType became a concrete model with a database table. Signal handlers query this table during migrations, but the table doesn't exist yet during 3.7.x→4.4.0 upgrades. The query failures poison the transaction and abort migrations.

This commits adds a objecttype_table_exists() helper and and uses it in three places:

  • has_feature() in netbox/models/features.py
  • update_object_types() in core/signals.py
  • Search backend cache() in search/backends.py

If core_objecttype table doesn't exist, operations return early instead of querying. Once table exists, normal operation resumes.

Pros

  • no migration changes
  • one helper function, three identical checks
  • easy to test, verify, and remove later if needed
  • queries PostgreSQL system catalogs for table existence - won't poison transactions

Cons

  • fixes symptoms, not root cause
  • touches 3 different files instead of one surgical fix
  • future code querying ObjectType during migrations could still fail/future developers might not know to add this check in new code
  • adds table introspection overhead (could cache if needed) to every has_feature() call
  • could introspect table name from model instead of hard-coding

In v4.4.0, ObjectType became a concrete model with a database table. Signal
handlers query this table during migrations, but the table doesn't exist yet
during 3.7.x→4.4.0 upgrades.

The query failures poison the transaction and abort migrations.

Added objecttype_table_exists() helper and three table existence checks:
- has_feature() in netbox/models/features.py
- update_object_types() in core/signals.py
- Search backend cache() in search/backends.py

If core_objecttype table doesn't exist, operations return early instead of
querying. Once table exists, normal operation resumes.
@jnovinger jnovinger marked this pull request as draft October 2, 2025 15:36
@jnovinger
Copy link
Member Author

Other approaches considered:

  1. Squashed migrations with updated dependencies (per @pheus's comment in Upgrade from v3.7.8 to v4.4.0 fails on migration users.0005_alter_user_table (core_objecttype missing) #20290) - Changes already-applied migrations, breaks 4.3.7 -> 4.4.0 upgrades
  2. Earlier ObjectType table creation via dependency restructuring - Same issues as squashing, multiple upgrade paths make this impractical
  3. Global signal disconnection during migrations - Too broad, loses legitimate functionality
  4. Dual feature detection (DB + in-memory fallback) - Re-adds code we just removed in v4.4.0
  5. Lazy ObjectType evaluation - Doesn't address direct ObjectType queries in core/signals.py and search/backends.py
  6. Document intermediate upgrade step requirement - Still viable, could complement this fix

@jnovinger jnovinger marked this pull request as ready for review October 2, 2025 20:16
@jeremystretch jeremystretch self-requested a review October 2, 2025 20:45
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.

Upgrade from v3.7.8 to v4.4.0 fails on migration users.0005_alter_user_table (core_objecttype missing)
1 participant