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
36774	catch DatabaseError instead of OperationalError in makemigrations check_consistent_history()	Piotr Kubiak		"This is a follow up to #31504.

I am proposing a change to the way that the `check_consistent_history()` behaves when an error occurs while accessing the database during the `makemigrations` command. Currently, only the `OperationalError` is caught and silenced.

In my setup, the database is accessible (I am able to connect), but database administrator implemented custom triggers that limit access for specific users. This makes my connection attempts fail with `DatabaseError` rather than `OperationalError`. But since the former is not silenced, `makemigrations` effectively requires a fully working database setup, which according to #31504 should not be necessary.

The original issue states that Django should ""fail gracefully if the connection to the database isn't available."" Therefore, I suggest catching the more general `DatabaseError` instead of `OperationalError`, as it covers more cases of database unavailability.

[https://github.com/piotr-kubiak/django/commit/c42edfdbed441afdeba213b502741ef3e8190d85 Proposed fix], I am happy to prepare a PR."	Cleanup/optimization	closed	Migrations	6.0	Normal	wontfix		Piotr Kubiak	Unreviewed	1	0	0	0	1	0