Migratiaon 0093 deletes all tracker history... what else?

[ChrisNolan]

Heads up: migration providers/0093_migrate_system_carriers_data.py appears to have a destructive side effect that is not clearly called out in the changelog.

At the end of the migration, each Carrier row with is_system=True is deleted after being moved to SystemConnection. Because that is a normal model delete, it can cascade through foreign-key relationships and delete associated data as well.

In my case, this resulted in about 60k tracking events being deleted.

The original PRD (PRDs/CARRIER_CONNECTION_ARCHITECTURE_UPGRADE.md) does say this migration is “MOVE data, not copy” and “forward-only,” with manual rollback intervention needed. The production architecture doc also lists providers/0093 as “Migrate system carriers data.” However, the changelog entry around Karrio 2026.1.2 only mentions “connections management for better data normalization and optimized reads,” which does not really warn operators that existing related data may be deleted via FK cascades.

Could this be documented more explicitly in the release notes / migration notes, and ideally guarded or changed so deleting the legacy carrier row does not cascade-delete historical data like tracking events? And future migrations to consider these cascades and appropriate move the records that are being rekeyed perhaps?

[sueun-dev]

this checks out as a real migration-ordering risk.

I only checked the cloned source/static migration graph at 8211f50, not a live DB migration. providers/0093_migrate_system_carriers_data.py iterates Carrier.objects.filter(is_system=True) and calls carrier.delete(), and its dependency list only points at providers/0092.... The legacy manager migration state still has Tracking.tracking_carrier, Pickup.pickup_carrier, and Shipment.selected_rate_carrier as CASCADE FKs to providers.Carrier; those are not removed until manager/0079_remove_carrier_fk_fields.py.

So unless something else has already forced manager 0079 to run first, providers 0093 can hit the old FK graph and delete tracking rows, including their stored events JSON. I'd add an explicit ordering/guard before 0093, or avoid ORM delete() until those legacy carrier FKs are removed/neutralized. The release notes should probably call out the backup/forward-only risk too.

[danh91]

Thanks @ChrisNolan, and @sueun-dev for confirming against the migration graph.

You are right — this was an omission. Deleting the legacy is_system carrier rows while the CASCADE FKs (tracking_carrier, pickup_carrier, selected_rate_carrier) were still in place let the delete cascade into history. Not intended, and the changelog did not warn about it.

What we will do:

• Guard providers/0093 so the legacy delete cannot cascade.
• Audit everything attached to carriers — trackers, pickups, manifests, shipments, rates — so each is moved safely before any delete.
• Add a clear data-loss note to the migration/release notes.

On the 60k events, I hope you had a backup to restore from — if not, let me know and I will help work out what is recoverable. Sorry for the loss, and thanks for flagging it.

[ChrisNolan]

Marta's #1123 raises some other migration concerns as well which might be worth a look when reviewing this one as well.