﻿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
33899	"migrations.RemoveField causes OperationalError ""no such column"" upon migration when db_index=True"	cessor	nobody	"== Description

I encountered the following error with django 4.1 in my Gitlab CI/CD Pipeline. When I bumped django versions from 4.0.7 to 4.1. my pipeline broke during the testing stage; specifically during db migrations. I have not changed any other source code. 

== Steps to reproduce

Minimal example attached. Run `make green` to see that it works with 4.0.7, run `make red` to see that it does not work with 4.1. It will build and exercise a docker container which installs all dependencies in isolation and sets up an example django app and run migrations. 

Manual steps: 

0. Install django 4.1
1. Create a new project
2. Create an app
3. Install app in project
4. Create a model
5. Add field on model, set `db_index=True`
6. Make migrations: `$ python manage.py makemigrations` 
7. Remove field from model
8. Make migrations: `$ python manage.py makemigrations` 
9. Apply migrations: `$ python manage.py migrate`

The migration fails with the following error (for an app called `web`, with a model called `Entity` with a field called `attribute` for example):

 {{{
Running migrations:
Applying contenttypes.0001_initial... OK
...
Applying sessions.0001_initial... OK
Applying web.0001_initial... OK
Applying web.0002_remove_entity_attribute...Traceback (most recent call last):
File ""/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py"", line 89, in _execute
 return self.cursor.execute(sql, params)
File ""/usr/local/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py"", line 357, in execute
 return Database.Cursor.execute(self, query, params)
sqlite3.OperationalError: error in index web_entity_attribute_d22c3fcb after drop column: no such column: attribute
}}}

== Details 
 
The above steps create a set of migrations where at the end a `RemoveField` migration is produced. Applying this migration fails for fields which had `db_index=True`. The example I attached uses a SlugField where `db_index` defaults to `True`, setting this parameter to False will apply the migration without this error. 

I reproduced the error with the following field types: TextField, IntegerField, SlugField, CharField, URLField"	Bug	new	Migrations	4.1	Normal		Migration Sqlite Docker		Accepted	1	0	1	0	1	0
