Hi there, yes I can add EMAIL_TIMEOUT in my applications and I am already doing that.
The reason I wanted to bring this up here is that I care about Django. This behavior goes against a well known concept of the Unix Philosophy which is to "Write programs which fail in a way that is easy to diagnose". I believe we can all agree that any potentially long running operation should have a default timeout after which the operation fails and a trace is left on a log somewhere for the system administrators to find I can't see the benefit in not failing, not leaving log traces and keeping an app blocked indefinitely. What are the benefits vs the downsides of such a change? Benefit: any issue in production systems will be quickly understood and dealt with. Downsides? Backward compatibility? Systems relying on the default timeout being set elsewhere? Anything else? Even if we allow configuring different email backends, I am still wonderfing: why do we think it's good to have an email sending operation which can potentially stall indefinitely? Best regards Federico On Friday, November 18, 2022 at 11:28:14 AM UTC-3 Michiel Beijen wrote: > Hi Mariusz, > > > Op 17 nov. 2022, om 18:18 heeft Mariusz Felisiak <felisiak...@gmail.com> > het volgende geschreven: > > > > "Why is there no default for EMAIL_TIMEOUT?" > > The Django's SMTP backend is a wrapper around smtplib.SMTP/SMTP_SSL and > we only pass the "timeout" parameter to the smtplib API, so I'd first ask > why there is no default value for a timeout parameter in smtplib. > > Well, Django’s docs say: > > > If unspecified, the default timeout will be the one provided by > socket.getdefaulttimeout(), which defaults to None(no timeout). > (ref https://docs.djangoproject.com/en/4.1/topics/email/#smtp-backend) > > So if you say: why is there no default value in smtplib, the smtplib > maintainer can so go one level up and ask why there is no default timeout > for `socket` :D > > Nevertheless, I would argue that having a timeout in django, set to a > rather conservative value such as 60 seconds, is much better than having no > timeout at all; especially because what the OP posted: > > > so at least if and when this happens, developers will find error traces > in the logs and quickly understand where the problem is coming from, > instead of spending hours to debug it like I did in the past week. > > In the typical scenario, people are much better off with specified > timeouts than with a timeout of None > > — > Michiel > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8ae42cd2-6c6c-47cb-8f56-7f0f46424df6n%40googlegroups.com.
