Changes between Initial Version and Version 1 of Ticket #36652, comment 24


Ignore:
Timestamp:
Oct 15, 2025, 10:25:48 AM (3 weeks ago)
Author:
Jayden Kneller

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #36652, comment 24

    initial v1  
    11So, after getting the test project down to 3 apps and 7 total migrations, I've tracked the issue down to the order that `self.graph.remove_replaced_nodes(key, migration.replaces)` gets called, which is determined by the order of `self.replacements.items()`, which is determined by the order of `migration_names`.  If the second migration in app_one is added to `self.replacements` before the first migration, since dictionaries are now ordered by default, then a cyclic dependency error occurs 100% of the time.  To confirm this you can rename migration `0002_squashed_initial`  to `0000_squashed_initial` and call `show_issue --use-fixed`.
    22
    3 If it is possible to mock the results that `self.replacements.items()` returns, then I we could have a test that guarantees the results of either a pass or CircularDependencyError based on the order of the migrations we return, but with the migration names being a set right now, that mock would still be susceptible to it only giving the result we want 50% of the time.  So, how do we write a test that will fail if the migration names is a set?
     3If it is possible to mock the results that `self.replacements.items()` returns, then we could have a test that guarantees the results of either a pass or CircularDependencyError based on the order of the migrations we return, but with the migration names being a set right now, that mock would still be susceptible to it only giving the result we want 50% of the time.  So, how do we write a test that will fail if the migration names is a set?
    44
    55Or, perhaps a better fix than making the migration names into a list, would be for self.replacements to be added to in the order that migrations would run.  But, I'm not sure how easy that would be.
Back to Top