AI analysis of django.core.mail fail_silently usage in real world projects:
(If you're reading these, I suggest starting with Gemini's.)
Research for https://forum.djangoproject.com/t/deprecating-or-changing-how-django-core-mail-handles-fail-silently/44278
User:
I need some help understanding how and where Django users are using the fail_silently option to the various django.core.mail functions. Given your wide-ranging knowledge of the whole variety of projects that use Django, could you provide some insight?
Background: We're preparing to implement a dict-based EMAIL_PROVIDERS feature. As part of that work, mail.get_connection() will be deprecated and replaced with mail.providers[alias] where alias is a key in the new EMAIL_PROVIDERS setting. This parallels similar Django settings and accessors around tasks, storages, caches, and databases.
The problem is, fail_silently is presented as a send-time option, but implemented as an EmailBackend constructor arg (instance configuration). That doesn't play well with mail.providers[alias], which needs to return a fully initialized backend instance. Two related problems are (1) Django's current code ignores fail_silently when also given a connection arg; and (2) Django's current docs (docs/topics/email.txt) are inconsistent and somewhat inaccurate/outdated: the smtp.EmailBackend ignores more than just smtp errors (docs haven't been updated for TLS/SSL SMTP), and third-party EmailBackends ignore whatever errors their authors decide (docs were written before pluggable EMAIL_BACKEND). (I've opened separate issues on both of those.)
We have a number of potential solutions to fail_silently with EMAIL_PROVIDERS. But in discussing them we realized none of us has a good understanding of how (or even whether) people are using fail_silently in real-world projects. I've done a GitHub code search, and I have some suspicions based on that. But my scattershot poking into public GitHub repos isn't necessarily representative of all the ways Django is used.
I'll share my suspicious with you next, but I wanted to get your unbiased thoughts first. You've seen a lot of Django projects. How are people using fail_silently with email?
django.core.mail functions that currently offer fail_silently:
Attachments: Attachment Name: CustomSystemPromptAttachment Attachments Kind: Visible Attachments Source: User / CustomSystemPromptAttachment Attachments Text:
Assistant:
This is a really thoughtful question, and it's clearly important groundwork for the EMAIL_PROVIDERS design. Let me share what I've observed across the broad landscape of Django projects.
By far the most common usage is passing fail_silently=True to send_mail() or EmailMessage.send() in contexts where email is a "nice to have" side effect, not the primary operation. The developer's intent is: "don't let a broken email setup crash the thing the user actually cares about."
Typical examples:
ConnectionRefusedError to show the user a 500 page after their data was already persisted.manage.py script that sends a summary report. fail_silently=True prevents the whole command from crashing (especially in cron, where the crash might go unnoticed anyway).# The classic pattern
user.save()
send_mail("Welcome!", body, from_email, [user.email], fail_silently=True)Most projects just rely on the default (False) and don't think about it. This covers:
fail_silently at all.Django itself calls these with fail_silently=True in the AdminEmailHandler logging handler — which makes sense, because you absolutely don't want a logging email failure to cause a recursive error storm. Many projects that call mail_admins() or mail_managers() directly follow this same pattern.
Very few projects pass fail_silently to get_connection() directly. When they do, it's almost always in a "batch send" pattern where they're managing the connection lifecycle themselves:
connection = get_connection(fail_silently=True)
connection.open()
for msg in messages:
msg.send() # uses the connection's fail_silently
connection.close()But honestly, this pattern is uncommon. Most developers use send_mail() or send_mass_mail() and let Django manage the connection.
Backends like django-ses, django-anymail, django-post-office, etc., have varying interpretations of fail_silently. Some respect it for API-level HTTP errors, some only for connection errors, some effectively ignore it because they queue emails to a database/broker and the "send" never fails synchronously. Many developers using these backends set fail_silently=True out of habit or cargo-culting without it having any real effect.
Here's what I think matters most for your work:
fail_silently is overwhelmingly a per-call-site decision, not a per-backend configuration. The same project might want fail_silently=True for a "new comment" notification and fail_silently=False for a password reset — both going through the same backend. This is the fundamental tension with it being a backend constructor arg.
Almost nobody is using fail_silently to distinguish between different backends. I've never seen a pattern like "use a fail-silent backend for notifications and a fail-loud backend for transactional email." People differentiate backends by provider (SES vs. SMTP vs. console), not by error handling behavior.
The "ignored when connection is passed" behavior is unknown to most developers. The vast majority of fail_silently=True usage is with send_mail() without a connection arg, so they never hit this. But it does mean the current semantics are already subtly broken for the few who do pass a connection.
What developers actually want is simple: a boolean that says "wrap the send in a try/except and swallow connection-ish errors." They don't think about it as backend configuration — they think about it as call-site error handling policy.
A significant minority don't use fail_silently at all and instead wrap sends in their own try/except (or handle it via Celery retries, dead-letter queues, etc.). For these developers, fail_silently is irrelevant.
Without prescribing a solution (since you said you have several candidates), the usage data strongly suggests that fail_silently should be a send-time parameter, not backend instance configuration. Moving it out of the backend constructor and into .send() / the convenience functions would:
connection is passed" inconsistencymail.providers[alias] clean — it returns a fully configured backend, and error handling policy is orthogonalThe tiny minority passing fail_silently to get_connection() would need a migration path, but that's already happening with the get_connection() deprecation anyway.
I'm curious to hear your GitHub search suspicions — I'd love to know if what I've described matches what you found in the data!
User:
Thanks, that's a really helpful analysis. I think we've also concluded that fail_silently needs to be handled per-send-operation, and moved out of backend configuration. There are two current proposals for that:
A. Implement fail_silently in EmailMessage.send(), by wrapping the call to connection.send_messages() in try / catch Exception. (The fail_silently param to EmailBackend constructors would be deprecated.) This leads to clearer behavior—all sending exceptions fail silently, without varying by email backend. But it might surprise some users who wouldn't want to swallow (e.g.) MemoryError.
B. Deprecate the fail_silently arg to send_mail(), send_mass_mail() and EmailMessage.send() (and get_connection() is being deprecated anyway). So it's only implemented in mail_admins() and mail_managers(), both of which would use a broad try/catch as in option A. Users who want to fail silently on other mail APIs would need to provide their own exception handling detailing exactly what they do or do not want to ignore.
C. Deprecate fail_silently entirely, for all django.core.mail functions.
Here's what my GitHub code search turned up:
fail_silently=True. (Nobody seems to use mail_managers(), other than Django's own BrokenLinksMiddleware which calls it with fail_silently=True.)Assistant: This is excellent data — and it aligns well with what I'd expect. Let me reflect on how your findings map to the three proposals.
The near-universal fail_silently=True on mail_admins() is very telling. These are the quintessential "email as side effect" calls — typically in error handlers, logging, and monitoring. If mail_admins() raises, you often get recursive failure cascades. This is a strong argument for at minimum keeping fail_silently on these two functions (i.e., Option B or A, not C).
This is the most important thing you found, and it cuts in an interesting direction:
For some of those, the surrounding code and comments suggested the developer was expecting
fail_silentlyto ignore all errors, not just transient connection problems.
This tells us that Option A's behavior is what many developers already assume they're getting. They write fail_silently=True and mentally model it as "this can't crash my view." The fact that current behavior is backend-dependent (and might not swallow all errors) means some of these developers have latent bugs they've never hit. Option A would actually fix their mental model.
Others suggested the developer was trying to avoid errors for undeliverable email addresses
This is a red herring usage — fail_silently can't help with this in any design. These developers have a misunderstanding that none of the three proposals need to accommodate. (Though it might be worth a docs callout.)
These are irrelevant to the design decision — they're not real production usage. Noise in the data.
some of these defaulted
fail_silentlytoTrue
This is interesting. These utility functions essentially created a project-level default of "fail silently." Under EMAIL_PROVIDERS, these wrappers likely go away entirely (replaced by mail.providers["notifications"] or whatever alias). So this usage pattern doesn't need to be preserved — it needs a migration path, which all three options provide via the get_connection() deprecation.
The mail_admins() data alone argues against this. Yes, developers can write their own try/except, but:
AdminEmailHandler and BrokenLinksMiddleware need this internally anyway — so you'd be hiding the try/except rather than removing it.mail_admins() is convenience. Forcing every caller to wrap it in try/except defeats that.It's the most conservative choice and respects the data: mail_admins() overwhelmingly uses fail_silently=True, and other call sites have diverse expectations. Telling developers "handle your own errors" for send_mail() / EmailMessage.send() is defensible.
But — your finding that many developers expect fail_silently=True to swallow everything means Option B will generate a wave of "how do I migrate?" questions. The answer ("wrap in try/except") is simple, but it's boilerplate that Django was previously handling. And some developers will get it wrong (catching too narrowly, or too broadly, or forgetting entirely).
Your data shows:
mail_admins() callers universally want fail_silently=True ✅ workssend_mail() / EmailMessage.send() callers who use fail_silently=True expect it to swallow all sending errors ✅ works — and is actually more correct than current behaviorfail_silently to discriminate between error types ✅ broad catch is fineThe MemoryError concern you raised is real but manageable. You'd catch Exception, not BaseException, so MemoryError, KeyboardInterrupt, and SystemExit would still propagate. That's the right boundary for almost everyone:
# Sketch of Option A's EmailMessage.send()
def send(self, fail_silently=False):
# ... existing connection setup ...
try:
return self.get_connection().send_messages([self])
except Exception:
if not fail_silently:
raise
return 0Since MemoryError is a BaseException (not Exception), it wouldn't be caught. The same goes for KeyboardInterrupt and SystemExit. The things that would be caught — smtplib.SMTPException, ConnectionRefusedError, TimeoutError, OSError, and whatever third-party backends raise — are exactly what developers intend to swallow.
Option A, with one refinement: document explicitly that fail_silently=True catches Exception subclasses only, and list the common ones for clarity. This:
mail_admins() / mail_managers() convenientEMAIL_PROVIDERS / mail.providers[alias] clean — backends are pure configuration, error policy is per-callThe only developers who might be surprised are those who were relying on fail_silently=True to swallow some errors but not others — and your data suggests that population is effectively zero.
User:
I need some help understanding how and where Django users are using the fail_silently option to the various django.core.mail functions. Given your wide-ranging knowledge of the whole variety of projects that use Django, could you provide some insight?
Background: We're preparing to implement a dict-based EMAIL_PROVIDERS feature. As part of that work, mail.get_connection() will be deprecated and replaced with mail.providers[alias] where alias is a key in the new EMAIL_PROVIDERS setting. This parallels similar Django settings and accessors around tasks, storages, caches, and databases.
The problem is, fail_silently is presented as a send-time option, but implemented as an EmailBackend constructor arg (instance configuration). That doesn't play well with mail.providers[alias], which needs to return a fully initialized backend instance. Two related problems are (1) Django's current code ignores fail_silently when also given a connection arg; and (2) Django's current docs (docs/topics/email.txt) are inconsistent and somewhat inaccurate/outdated: the smtp.EmailBackend ignores more than just smtp errors (docs haven't been updated for TLS/SSL SMTP), and third-party EmailBackends ignore whatever errors their authors decide (docs were written before pluggable EMAIL_BACKEND). (I've opened separate issues on both of those.)
We have a number of potential solutions to fail_silently with EMAIL_PROVIDERS. But in discussing them we realized none of us has a good understanding of how (or even whether) people are using fail_silently in real-world projects. I've done a GitHub code search, and I have some suspicions based on that. But my scattershot poking into public GitHub repos isn't necessarily representative of all the ways Django is used.
I'll share my suspicious with you next, but I wanted to get your unbiased thoughts first. You've seen a lot of Django projects. How are people using fail_silently with email?
django.core.mail functions that currently offer fail_silently:
Assistant:
It is great to hear about the work on the EMAIL_PROVIDERS feature! Bringing the email configuration in line with DATABASES, CACHES, and STORAGES is a fantastic architectural step.
You've hit on a classic Django historical quirk. fail_silently was introduced early in Django's lifecycle (well before pluggable backends and the rise of async task queues like Celery). It was designed as a quick, developer-friendly way to prevent a broken SMTP configuration from crashing a synchronous HTTP request.
Based on my exposure to a wide variety of Django codebases—ranging from legacy monoliths to modern API-driven backends—here is a breakdown of how and why developers use fail_silently in the wild.
In smaller projects, or in codebases that haven't adopted an async task queue (like Celery, RQ, or Huey), emails are sent directly within the request-response cycle.
If an SMTP server hiccups, hangs, or rejects authentication during a user registration or password reset, developers use fail_silently=True to ensure the user still sees a "Success" page (a 200 OK or 302 Redirect) rather than a 500 Internal Server Error.
send_mail() and EmailMessage.send().When developers write custom error handlers, middleware, or management commands that need to notify the team of a failure, they frequently use fail_silently=True.
mail_admins() and mail_managers().Many projects dynamically set fail_silently based on the environment. Instead of configuring a console or dummy backend for local development or staging, some developers will do something like:
send_mail(..., fail_silently=not settings.IS_PRODUCTION)
When looping through a queryset to send emails to hundreds of users, some developers will use fail_silently=True on individual EmailMessage.send() calls to prevent a single bad email address (which might trigger an SMTP 550 User unknown) from aborting the entire loop.
send_mass_mail() or managing the connection manually, but it is a very common misuse of the flag.Your observation that fail_silently is presented as a "send-time" option but implemented as "instance-time" configuration is spot on. This mismatch wasn't a huge deal when get_connection() instantiated a brand-new backend class every time you called send_mail().
However, as you move toward mail.providers[alias] returning a fully initialized backend (presumably a singleton or cached instance per thread, like database connections), fail_silently becomes a major statefulness problem. If Thread A calls msg.send(fail_silently=True) while Thread B is using the same backend instance, you can't mutate the backend's fail_silently attribute without a race condition.
It is worth noting that the reliance on fail_silently has decreased significantly in modern, mid-to-large Django apps.
Nowadays, best practice dictates that emails are dispatched via background workers (Celery, etc.). In a background task, you want the email to fail loudly so the worker can catch the exception, log it, and apply a retry backoff strategy. In these modern setups, fail_silently=True is actually an anti-pattern because it silently swallows failures, causing emails to be lost with no trace in the worker logs.
I'm very curious to hear if these patterns align with the suspicions you gathered from your GitHub code search. What did you find, and what potential solutions is the team discussing for the EMAIL_PROVIDERS transition?
User: Thanks, that's a really helpful analysis, and matches a lot of the anecdotal evidence I saw in the GitHub code search.
I think we've also concluded that fail_silently needs to be handled per-send-operation, and moved out of backend configuration. There are two current proposals for that:
A. Implement fail_silently in EmailMessage.send(), by wrapping the call to connection.send_messages() in try / catch Exception. (The fail_silently param to EmailBackend constructors would be deprecated.) This leads to clearer behavior—all sending exceptions fail silently, without varying by email backend. But it might surprise some users who wouldn't want to swallow (e.g.) MemoryError.
B. Deprecate the fail_silently arg to send_mail(), send_mass_mail() and EmailMessage.send() (and get_connection() is being deprecated anyway). So it's only implemented in mail_admins() and mail_managers(), both of which would use a broad try/catch as in option A. Users who want to fail silently on other mail APIs would need to provide their own exception handling detailing exactly what they do or do not want to ignore.
C. Deprecate fail_silently entirely, for all django.core.mail functions.
Here's what my GitHub code search turned up (I didn't note the repo dates, so keep in mind some of these may be 5-10 years old):
fail_silently=True. (Nobody seems to use mail_managers(), other than Django's own BrokenLinksMiddleware which calls it with fail_silently=True.)Assistant: Your GitHub search results are absolutely fascinating! They paint a perfect (and slightly terrifying) picture of how legacy code practices linger in the wild. The hardcoded, commented-out email addresses used for production debugging gave me a good chuckle—we've all been there in a moment of desperation, even if we don't want to admit it!
Looking at the three proposals for the EMAIL_PROVIDERS transition, here is an analysis of each from the perspective of modern Python/Django best practices and backward compatibility.
Exception (or even BaseException) is notoriously anti-pattern in Python. As you noted, swallowing a MemoryError, a TypeError (e.g., passing an integer instead of a string for a recipient), or a ValueError means developers will spend hours debugging why their emails aren't sending, completely unaware that Django is quietly eating the traceback.fail_silently actually does.try/except blocks in send_mail() calls, meaning they have to think about which exceptions they actually want to catch (e.g., TimeoutError, SMTPException). Meanwhile, it preserves the vital fail-safe behavior of mail_admins() to prevent infinite error-logging cascades.send_mail(..., fail_silently=True). However, modernizing a framework sometimes requires breaking eggs.mail_admins(). If mail_admins() throws an exception, and that exception triggers an error handler that calls mail_admins(), you create an infinite loop that can crash the host server.mail_admins() and error handling legitimately need a "do your best but don't crash me" mechanism.The fundamental flaw with fail_silently is that because email backends are pluggable, Django can't know what exceptions to catch. An SMTP backend throws smtplib.SMTPException. A SendGrid API backend might throw requests.exceptions.RequestException. An AWS SES backend might throw botocore.exceptions.ClientError.
Because Django can't safely catch a unified EmailDeliveryException, Option B is the most honest approach: tell the developer, "We don't know what backend you're using, so we don't know what network errors to catch. Write your own exception handler."
Are you leaning towards Option B as well, or is the concern over the massive deprecation noise pushing the team towards Option A?
User:
I need some help understanding how and where Django users are using the fail_silently option to the various django.core.mail functions. Given your wide-ranging knowledge of the whole variety of projects that use Django, could you provide some insight?
Background: We're preparing to implement a dict-based EMAIL_PROVIDERS feature. As part of that work, mail.get_connection() will be deprecated and replaced with mail.providers[alias] where alias is a key in the new EMAIL_PROVIDERS setting. This parallels similar Django settings and accessors around tasks, storages, caches, and databases.
The problem is, fail_silently is presented as a send-time option, but implemented as an EmailBackend constructor arg (instance configuration). That doesn't play well with mail.providers[alias], which needs to return a fully initialized backend instance. Two related problems are (1) Django's current code ignores fail_silently when also given a connection arg; and (2) Django's current docs (docs/topics/email.txt) are inconsistent and somewhat inaccurate/outdated: the smtp.EmailBackend ignores more than just smtp errors (docs haven't been updated for TLS/SSL SMTP), and third-party EmailBackends ignore whatever errors their authors decide (docs were written before pluggable EMAIL_BACKEND). (I've opened separate issues on both of those.)
We have a number of potential solutions to fail_silently with EMAIL_PROVIDERS. But in discussing them we realized none of us has a good understanding of how (or even whether) people are using fail_silently in real-world projects. I've done a GitHub code search, and I have some suspicions based on that. But my scattershot poking into public GitHub repos isn't necessarily representative of all the ways Django is used.
I'll share my suspicious with you next, but I wanted to get your unbiased thoughts first. You've seen a lot of Django projects. How are people using fail_silently with email?
django.core.mail functions that currently offer fail_silently:
Assistant: Great question — and you’re focusing on exactly the seam where API shape and real usage collide.
In real-world Django codebases, fail_silently is used, but not heavily, and when used it’s usually one of these patterns:
fail_silently=True added years ago, never revisited).Much less common (and generally discouraged): using fail_silently=True for critical transactional emails without alternate observability.
Most common in older code and admin-ish flows:
This is probably the biggest bucket.
Common when teams wrap email in a utility module.
EmailMessage.send() gets used when attachments/alternatives are needed, and fail_silently is passed there for “best effort.”
Seen in code that sends several messages using one connection for efficiency.
fail_silently is effectively treated as a connection policyLess common than people think. Teams that care about ops usually prefer explicit logging/monitoring over silent failure. Still appears in legacy setups.
In background jobs, many teams prefer exceptions raised (for retries/alerting), so fail_silently=False is more common there.
If True is used, it’s often because they already handle outcome via return values/logs.
A lot of projects pass fail_silently assuming “ignore just transient SMTP-ish delivery problems,” but backend behavior is broader/inconsistent, as you noted. In practice, many teams are not relying on a precise exception contract — they’re relying on “don’t crash this path.”
That suggests the semantic intent in user code is usually:
not:
That mismatch supports your concern about keeping it as backend-instance state.
If you move to mail.providers[alias] returning initialized backend instances, users will likely expect:
raise vs swallow) to be call-site explicit, or at least overrideable per send.fail_silently behavior to remain predictable during deprecation.So I’d expect least-friction migration if silent-vs-raise is treated as a send-time behavior, even if backend defaults exist.
Given how people actually use it, compatibility pain will center on:
connection=... and fail_silently=... expecting per-call controlfail_silently mechanicallyIf you change semantics, teams will mostly need:
fail_silently is ignored,If you want, share your hypotheses next and I can pressure-test them against these usage patterns and help sketch a migration matrix (old call forms → new provider-based equivalents + warning strategy).
User: Thanks, that's a really helpful analysis, and matches a lot of the anecdotal evidence I saw in the GitHub code search.
I think we've also concluded that fail_silently needs to be handled per-send-operation, and moved out of backend configuration. There are two current proposals for that:
A. Implement fail_silently in EmailMessage.send(), by wrapping the call to connection.send_messages() in try / catch Exception. (The fail_silently param to EmailBackend constructors would be deprecated.) This leads to clearer behavior—all sending exceptions fail silently, without varying by email backend. But it might surprise some users who wouldn't want to swallow (e.g.) MemoryError.
B. Deprecate the fail_silently arg to send_mail(), send_mass_mail() and EmailMessage.send() (and get_connection() is being deprecated anyway). So it's only implemented in mail_admins() and mail_managers(), both of which would use a broad try/catch as in option A. Users who want to fail silently on other mail APIs would need to provide their own exception handling detailing exactly what they do or do not want to ignore.
C. Deprecate fail_silently entirely, for all django.core.mail functions.
Here's what my GitHub code search turned up (I didn't note the repo dates, so keep in mind some of these may be 5-10 years old):
fail_silently=True. (Nobody seems to use mail_managers(), other than Django's own BrokenLinksMiddleware which calls it with fail_silently=True.)Assistant: This is excellent research, and honestly it strongly argues for A (with one safety refinement), not B/C.
That best matches how people already think it works:
Your findings (especially contact/signup/comment/purchase flows and utility wrappers) are exactly that mental model.
If you do broad exception handling in EmailMessage.send(), I’d recommend:
Exception, but re-raise a tiny set of truly critical exceptions (MemoryError, maybe RecursionError) even when fail_silently=True.Why: this avoids pathological “process is unhealthy but we hide it” behavior, while preserving the practical “don’t crash app flow on mail errors” contract users expect.
(You still would not catch BaseException, so KeyboardInterrupt/SystemExit continue to behave correctly.)
B is “clean” from an API-purity standpoint, but likely painful in real projects:
send_mail(..., fail_silently=True)),try/except into app code everywhere,Given your own search results, that’s a high-friction migration for modest conceptual gain.
C is probably too disruptive unless you’re prepared for a long migration window and substantial ecosystem churn.
Also, your data suggests many teams do use this feature intentionally for best-effort behavior.
If you go with A, document this explicitly:
fail_silently is a send-operation policy.That directly addresses the historical doc ambiguity you called out.
If useful, I can draft a concrete deprecation/migration note format (release-note wording + warning text + behavior table for each API).