id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32689	Infinite AlterField Migrations due to default callable object missmatch	Samuel Bishop	nobody	"`makemigration` will generate infinite migrations if the callable path is miss-matched such that you end up with two discreet callable objects (I'm still trying to identify where exactly the migration framework is generating this missmatch, I can see the difference stepping through `MigrationAutodetector.generate_altered_fields` in the debugger but I'm not sure if the root cause is inside `generate_altered_fields`, another method on `MigrationAutodetector` or somewhere else entirely...) then the same migration is generated every time you run the command which results in no actual change to the database.

In my case it's from a custom field library being used as a primary key.

I was importing `from ulid.api import new as new_ulid` and setting `default=new_ulid`, but unless I swap to `import ulid.api.api` and set `default=ulid.api.api.Api.new` I just get a new identical migration altering the field's default value to `ulid.api.api.Api.new` every time i run `makemigrations`

I would have expected either a clear warning detailing why my choice of callable object for the `default=` will cause issues, or I would have expected `makemigrations` to not mutate my callable like this.

Root cause: Turns out this is a serialisation fault. The migration serialiser doesn't throw any kind of error or warning and just mutates the callable instead of preventing me from using an invalid default callable that the migration framework wont be able to serialise. A simple wrapper function added to the custom field library solves the matter entirely, however the underlying issue of the migration framework behaviour is worth looking at improving."	Bug	new	Migrations	3.2	Normal		infinite, makemigrations, migrations, callable, default, field		Unreviewed	0	0	0	0	0	0