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
37433	Escaped database error messages logged by `Q.check()`	Natalia Bidart	Natalia Bidart	"`Q.check()`, used by `CheckConstraint.validate()` and by `UniqueConstraint.validate()` with a `condition`, catches `DatabaseError` and logs it to the `django.db.models` logger:

{{{#!python
logger.warning(""Got a database error calling check() on %r: %s"", self, e)
}}}

Database error messages can include the values being validated, which may originate from user input (for example through `ModelForm` validation). These messages are currently logged as-is. For defense in depth, and for consistency with other logging call sites, `Q.check()` should log the message through `django.utils.log.log_message()` so that its content is escaped, and trim it to a reasonable length.

The trimming logic for large values is currently duplicated in `django/views/debug.py` and `django/contrib/gis/gdal/raster/source.py`. A small `trim_value()` helper in `django.utils.text` could be shared by those two places and by `Q.check()`.

Separately, the fact that `BaseConstraint.validate()` treats a constraint as satisfied when evaluating it raises a database error (logging a warning and leaving the error to surface on `save()`) is not documented. A short note in the constraints reference would help developers understand why a condition that can fail to evaluate does not act as validation."	Cleanup/optimization	assigned	Database layer (models, ORM)	dev	Normal		not-security	Jake Howard	Accepted	0	0	0	0	0	0