[Django] #33150: EmailBackend.write_message crashes when self.steam is BufferedWriter

0 views
Skip to first unread message

Django

unread,
Sep 28, 2021, 1:55:45 AM9/28/21
to django-...@googlegroups.com
#33150: EmailBackend.write_message crashes when self.steam is BufferedWriter
-----------------------------------------+------------------------
Reporter: Bernd Wechner | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
I have no idea what's going on here alas, but I had to fix this fast
locally. I have three versions of the one Danjgo site running, dev,
sandbox and live respectively. I run near identically on each one, and as
I fix things on dev test them on sandbox and publish them on live. They
are not picture perfect identical although sandbox and live certainly come
very close.

Fortunately I can debug all three with PyDev (awesome!) and this is the
first time I've had to remotely debug the live site, as it was crashing
when users attempt to reset their passwords. it crashed here:

https://github.com/django/django/blob/4ffada36097ceccfd6f0d358217ac3c40d2a729c/django/core/mail/backends/console.py#L21

and it did so because {{{self.stream}}} at this point, on the live server
was of type {{{BufferedWriter}}} while on the sandbox and dev sites it is
of type {{{TextIOWrapper}}}.

The latter take strings, and is fed a string at this line. Alas the former
does not, it only takes byte strings.

I have no idea how or why these sites deviate in self.stream here, or
whence that stemeth. I would like to know, but that would a research
project I lack time for in the urgent need to get this site live.

So I patched that method and it now reads:

{{{
def write_message(self, message):
#import pydevd; pydevd.settrace('192.168.0.11',
stdoutToServer=True, stderrToServer=True)
msg = message.message()
msg_data = msg.as_bytes()
charset = msg.get_charset().get_output_charset() if
msg.get_charset() else 'utf-8'
if self.stream.mode.endswith('b'):
self.stream.write(msg_data)
self.stream.write(b'\n')
self.stream.write(b'-' * 79)
self.stream.write(b'\n')
else:
msg_data = msg_data.decode(charset)
self.stream.write('%s\n' % msg_data)
self.stream.write('-' * 79)
self.stream.write('\n')
}}}

(you can see my breakpoint in the pydev debugger commented out there)

There are two distinct issues here:

1. How is it possible that self.stream is set to an incompatible type?
2. This method should really be more robust (as pictured) anyhow ...

--
Ticket URL: <https://code.djangoproject.com/ticket/33150>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Sep 28, 2021, 2:27:19 AM9/28/21
to django-...@googlegroups.com
#33150: EmailBackend.write_message crashes when self.steam is BufferedWriter
-------------------------------+--------------------------------------

Reporter: Bernd Wechner | Owner: nobody
Type: Uncategorized | Status: closed
Component: Core (Mail) | Version: 3.2
Severity: Normal | Resolution: invalid

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Mariusz Felisiak):

* status: new => closed
* resolution: => invalid
* component: Uncategorized => Core (Mail)


Comment:

Thanks for the report, however it looks like a support question and Trac
is not one of
[https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
support channels]. Moreover the console backend is not intended for use in
production -- it is provided as a convenience that can be used during
development (see [https://docs.djangoproject.com/en/stable/topics/email
/#console-backend docs]).

--
Ticket URL: <https://code.djangoproject.com/ticket/33150#comment:1>

Reply all
Reply to author
Forward
0 new messages