[chores:fix] Prevented dangling relations from breaking radius migrations#726
Conversation
📝 WalkthroughWalkthroughThis pull request adds defensive filtering to migration helpers to exclude dangling foreign-key references during RegisteredUser and PhoneToken data-copy operations. Three new helper functions filter querysets to validate that referenced users and organizations still exist. RegisteredUser forward/reverse migrations and the multitenant path now use these filters to avoid copying orphaned rows, and PhoneToken organization population is updated to derive organization IDs only from valid membership references. Tests validate the new filtering behavior with direct FK corruption via raw SQL. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Historical databases can contain dangling relations in RegisteredUser and OrganizationUser rows. The RegisteredUser UUID and multitenant migration helpers assumed these foreign keys were always valid and could fail during upgrades when copying or backfilling data. This bug was observed as a foreign key violation while inserting rows into openwisp_radius_registereduser during the 0045/0046 migration chain because a copied RegisteredUser.user_id no longer existed in openwisp_users_user. The same class of issue could also affect OrganizationUser-based backfills when a membership pointed to a missing user or organization. This change filters invalid RegisteredUser and OrganizationUser rows before reusing their foreign keys in migration helpers, preserving the existing behavior for valid data while safely skipping broken legacy references. Focused regression tests were added to cover dangling RegisteredUser.user_id, dangling OrganizationUser.user_id and dangling OrganizationUser.organization_id cases.
5c06a8f to
b5afc38
Compare
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (2 files)
Reviewed by gpt-5.4-20260305 · 238,778 tokens |
Checklist
Description of Changes
Historical databases can contain dangling relations in RegisteredUser and OrganizationUser rows. The RegisteredUser UUID and multitenant migration helpers assumed these foreign keys were always valid and could fail during upgrades when copying or backfilling data.
This bug was observed as a foreign key violation while inserting rows into openwisp_radius_registereduser during the 0045/0046 migration chain because a copied RegisteredUser.user_id no longer existed in openwisp_users_user. The same class of issue could also affect OrganizationUser-based backfills when a membership pointed to a missing user or organization.
This change filters invalid RegisteredUser and OrganizationUser rows before reusing their foreign keys in migration helpers, preserving the existing behavior for valid data while safely skipping broken legacy references. Focused regression tests were added to cover dangling RegisteredUser.user_id, dangling OrganizationUser.user_id and dangling OrganizationUser.organization_id cases.