Context Navigation

Changes between Initial Version and Version 1 of Ticket #37493

initial	v1
120	120	Note that the `Confounder` operation actually does matter. If the PK `AlterField` operation goes first, it works as expected. An operation on `Parent` or `Child` instead of `Confounder` doesn't trigger it. It also matters that 0001 and 0002 are run together. If you apply 0001 and then 0002 in separate `migrate` commands, you get the correct types.
121	121
	122	It also isn't postgres-specific, you can reproduce on sqlite with a `CharField` primary key going from `max_length=10` to `20`. `app_child.parent_id` will stay `varchar(10)`.
	123
122	124	I found this while fuzz testing a migration extension that manages database views with Django migrations. The fuzzer makes random model and view changes, runs `makemigrations`, and applies the migrations in every order their dependencies allow, forwards and backwards. It uses an oracle that compares the schema in the Postgres catalogs after each `migrate` with the schema the generated models describe, including column types. After one migration was unapplied and applied again, a foreign key column came out `integer` while the primary key it points at was `bigint`. The extension copies the same pattern `SeparateDatabaseAndState.database_forwards` uses, so I tried to find a minimal repro with `SeparateDatabaseAndState` alone.