Opened 9 years ago

Closed 2 years ago

#24475 closed New feature (wontfix)

Add a new testconnections management command

Reported by: Loek van Gent Owned by: Alex Morozov
Component: Core (Management commands) Version: dev
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


Add a management command to check connection to mail server (without actually sending emails). This command can be extended later with testing other connections like caching ad maybe other settings.

Here's a snippet that would test a smtp connection

from django.core import mail
from django.core.mail.backends.smtp import EmailBackend

    def _check_mail_settings(self):
        connection = mail.get_connection()
        if isinstance(connection, EmailBackend):

Change History (16)

comment:1 Changed 9 years ago by Loek van Gent

Component: UncategorizedCore (System checks)

comment:2 Changed 9 years ago by Tim Graham

Component: Core (System checks)Core (Management commands)
Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature
Version: 1.7master

comment:3 Changed 9 years ago by John Giannelos

Owner: changed from nobody to John Giannelos
Status: newassigned

comment:4 Changed 8 years ago by John Moses

Is this still needed with the sendtestemail command?

comment:5 Changed 8 years ago by John Giannelos

Owner: John Giannelos deleted
Status: assignednew

comment:6 Changed 8 years ago by Loek van Gent

The idea is that this commands will test all kind of connections. This should only test if the mailserver is reachable and if you can log in with the given credentials, without actually sending emails.
We could later extend it with testing the settings/servers for chaching, celery etc.

Version 0, edited 8 years ago by Loek van Gent (next)

comment:7 Changed 8 years ago by Alex Morozov

Does it make sense to extend the system check framework with this kind of functionality? If that's ok, I'd try to draft some code.

comment:8 Changed 8 years ago by Tim Graham

Currently the system check framework is limited to static code analysis. Adding a new option like check --conections could work. I think these checks shouldn't run if that option isn't specified though.

comment:9 Changed 8 years ago by Alex Morozov

Owner: set to Alex Morozov
Status: newassigned

@timgraham, thank you. Will have a closer look on this. Should the check --connections test only connections as its name implies, or maybe we should rename the option? My English is pretty poor, but wouldn't something like --with-connections be more clear?

comment:10 Changed 8 years ago by Tim Graham

I think testing only connections is fine as it's a fundamentally different type of check from the static code checks but this is subject to the implementation, what checks we actually add, and what others think is best.

comment:11 Changed 8 years ago by Shai Berger

What do we gain by folding it into the system checks framework? How is that better than a separate command?

Also, is this intended mostly for "local" connections (mail, database, job-queue broker) or are "remote" connections (OAuth providers, other APIs) also on the plate?

comment:12 Changed 8 years ago by Tim Graham

One advantage of the the checks framework is that it makes it easy for users to register new checks if they want to check parts of their infrastructure that Django core doesn't know about.

I don't know the answer to your second question. I have thought that it might be better to start this as a third-party project to allow it to iterate more quickly, see if it gains any traction and if so, how exactly users end up using it.

comment:13 Changed 8 years ago by Alex Morozov

@shaib, the whole "checks" framework seems to me to be a registry of various checks of "system health". Remote dependencies are (for me) the perfect fit for that. Introducing another command seems to be an real cognitive overhead.
As for the "remote" connections - I'm quite fine with that, it would help a lot on deploy. Though such kind of checks surely should be warnings, not errors.

@timgraham, speaking of starting this as a separate project - I'm not sure there's an easy way to register those tests as 'checks', while having the check framework skipping them for the 'common' run. And implementing a separate 'remote checks' registry (mostly copy-pasting the checks' code) looks like a total mess for me.

If we could mark some checks tags to be skipped at the plain run (more generic way of that "deploy" thing), would it be of help?

comment:14 Changed 8 years ago by Tim Graham

Making the checks framework more extensible does seem interesting but may be a bit tricky and will obviously delay being able to release this as a third-party app until the next Django feature release. It might involve a little copy/pasting from Django, but I think it should be straightforward to mimic a simple version of Django's check registry in a third-party app/command.

comment:15 Changed 8 years ago by Alex Morozov

@timgraham, I've got your reservations, thank you. I'll try to draft a third-party package, or to make use of some existing one.

P.S. After a bit of googling, I have found an interesting package. Do you know any of similar libraries, maybe, even more generic?

comment:16 Changed 2 years ago by Mariusz Felisiak

Resolution: wontfix
Status: assignedclosed
Triage Stage: AcceptedUnreviewed

There are already 3rd-party packages that check the status of various connections e.g. django-health-check. We need to reach a strong consensus on the DevelopersMailingList before incorporating them into Django.

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