chore(devex): Migrate Error Tracking Models to Products Structure

[webjunkie]

Migrated error tracking models from posthog/models/error_tracking/ to products/error_tracking/backend/ as part of the modularization effort to better organize PostHog's codebase into product-focused directories.

What Changed

📁 File Structure Migration

From:

posthog/models/error_tracking/
├── error_tracking.py
├── hogvm_stl.py
├── sql.py
└── test/
    └── test_error_tracking.py

To:

products/error_tracking/backend/
├── models.py  (combined from all model files)
├── hogvm_stl.py
├── sql.py
└── test/
    └── test_error_tracking.py

🔄 Import Updates Across Codebase

All imports were automatically updated:

• from posthog.models.error_tracking import ErrorTrackingIssue → from products.error_tracking.backend.models import ErrorTrackingIssue
• from posthog.models.error_tracking.sql import ... → from products.error_tracking.backend.sql import ...
• from posthog.models.error_tracking.hogvm_stl import ... → from products.error_tracking.backend.hogvm_stl import ...

🔗 Foreign Key References

Converted direct class references to string-based references for better app separation:

• ForeignKey(Team, ...) → ForeignKey("posthog.Team", ...)
• ForeignKey(User, ...) → ForeignKey("posthog.User", ...)
• ForeignKey(Role, ...) → ForeignKey("ee.Role", ...) (Role is in the ee app)

💾 Database Compatibility

• All model Meta classes retain their db_table settings
• No database migrations required - tables remain unchanged

⚙️ Django Configuration

• Error tracking app remains registered in Django
• Models are now loaded from products.error_tracking.backend instead of posthog.models.error_tracking
• Admin classes properly moved and registered

Models Moved

• ErrorTrackingIssue
• ErrorTrackingIssueFingerprintV2
• ErrorTrackingStackFrame
• ErrorTrackingSymbolSet
• ErrorTrackingIssueAssignment
• ErrorTrackingAssignmentRule
• ErrorTrackingGroupingRule
• ErrorTrackingSuppressionRule
• ErrorTrackingRelease
• ErrorTrackingExternalReference
• ErrorTrackingIssueFingerprint

Impact

• ✅ No breaking changes - All existing functionality preserved
• ✅ No database migrations needed - Table names unchanged
• ✅ Backward compatible - All imports automatically updated
• ✅ Better code organization - Error tracking is now a self-contained product module
• ✅ Cleaner dependency graph - Reduced cross-module dependencies through string-based FK references

Files Affected

• Moved: 4 files from posthog/models/error_tracking/
• Updated imports: ~20+ files across the codebase including:
  • API endpoints (posthog/api/error_tracking.py)
  • Management commands (posthog/management/commands/sync_exceptions_to_clickhouse.py)
  • Query runners (posthog/hogql_queries/error_tracking_query_runner.py)
  • DAGs (dags/symbol_set_cleanup.py)
  • Tests and other dependencies

This migration establishes error tracking as a proper product module while maintaining full backward compatibility and requiring no database changes.

[greptile-apps]

_{27 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

syntax: Foreign key reference uses incorrect app name. Should be "products.error_tracking.backend.errortrackingrelease" or just "error_tracking.errortrackingrelease" for consistency with other references in the migration.

Suggested change

	null=True, on_delete=django.db.models.deletion.CASCADE, to="error_tracking.errortrackingrelease"
	),
	),
	models.ForeignKey(
	null=True, on_delete=django.db.models.deletion.CASCADE, to="error_tracking.errortrackingrelease"
	),

Prompt To Fix With AI

This is a comment left during a code review.
Path: products/error_tracking/backend/migrations/0001_initial_migration.py
Line: 138:140

Comment:
syntax: Foreign key reference uses incorrect app name. Should be `"products.error_tracking.backend.errortrackingrelease"` or just `"error_tracking.errortrackingrelease"` for consistency with other references in the migration.

```suggestion
                    models.ForeignKey(
                        null=True, on_delete=django.db.models.deletion.CASCADE, to="error_tracking.errortrackingrelease"
                    ),
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

syntax: Foreign key reference uses incorrect app name. Should be "error_tracking.errortrackingsymbolset" for consistency with other references in the migration.

Suggested change

	on_delete=django.db.models.deletion.SET_NULL,
	to="error_tracking.errortrackingsymbolset",
	),
	models.ForeignKey(
	null=True,
	on_delete=django.db.models.deletion.SET_NULL,
	to="error_tracking.errortrackingsymbolset",
	),

Prompt To Fix With AI

This is a comment left during a code review.
Path: products/error_tracking/backend/migrations/0001_initial_migration.py
Line: 184:186

Comment:
syntax: Foreign key reference uses incorrect app name. Should be `"error_tracking.errortrackingsymbolset"` for consistency with other references in the migration.

```suggestion
                    models.ForeignKey(
                        null=True,
                        on_delete=django.db.models.deletion.SET_NULL,
                        to="error_tracking.errortrackingsymbolset",
                    ),
```

How can I resolve this? If you propose a fix, please make it concise.

[github-actions]

Migration SQL Changes

Hey 👋, we've detected some migrations on this PR. Here's the SQL output for each migration, make sure they make sense:

posthog/migrations/0867_initial_migration.py

BEGIN;
--
-- Custom state/database change combination
--
-- (no-op)
COMMIT;

products/error_tracking/backend/migrations/0001_initial_migration.py

BEGIN;
--
-- Custom state/database change combination
--
-- (no-op)
COMMIT;

[orian]

Ok for ClickHouse.