Opened 6 months ago

Closed 6 months ago

Last modified 6 months ago

#35577 closed Bug (invalid)

runserver leaves a database connection infinitely unclosed as a result of its migration check

Reported by: Klaas van Schelven Owned by:
Component: Database layer (models, ORM) Version: 4.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Klaas van Schelven)

When starting the "Debug server" (runserver command), Django does a check on the migrations ("check_migrations").

This check touches the DB (to see which migrations have run)

However, after the call there's no call to connection.close(). (or some conditional form thereof).

This means that for the debugserver one connection will remain permanently open. The name of the thread on which this connection is created is django-main-thread.

Looking at the documentation the per-request model of connection lifetimes is clear. Other than that the following caveat is documented:

If a connection is created in a long-running process, outside of Django’s request-response cycle, the connection will remain open until explicitly closed, or timeout occurs.

But one would assume that this caveat applies to connections opened by the developers themselves, not by what Django does internally.

Here's the call to check_migrations:
https://github.com/django/django/blob/stable/4.2.x/django/core/management/commands/runserver.py#L136

I've seen this behavior on Django 4.2, have not tested it with a more recent version yet, but I don't have a reason to think it's been solved in the meantime.

Change History (3)

comment:1 by Klaas van Schelven, 6 months ago

Description: modified (diff)

comment:2 by Mariusz Felisiak, 6 months ago

Component: UncategorizedDatabase layer (models, ORM)
Resolution: invalid
Status: newclosed
Type: UncategorizedBug

Django 4.2 is in extended support and no longer receives bugfixes (except security patches). Moreover, it was fixed in Django 5.1 (bcccea3ef31c777b73cba41a6255cd866bf87237).

comment:3 by Klaas van Schelven, 6 months ago

it was fixed in Django 5.1

I'm glad it was, this is indeed the fix.

I still can't find any other bug report leading up to the fix so perhaps the present ticket can lead others to the fix.

Note: See TracTickets for help on using tickets.
Back to Top