Re: [Django] #30448: close_if_unusable_or_obsolete should skip connections in atomic block for autocommit check

[Django]

#30448: close_if_unusable_or_obsolete should skip connections in atomic block 
for
autocommit check
-+-
 Reporter:  Daniel Hahler|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Janzen):

 * cc: Jon Janzen (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018feb9e3466-58a8267f-e6d1-4b76-b8fe-5c9a9d5c5dd9-00%40eu-central-1.amazonses.com.

[Django] #35498: Race-condition using Django pylibmc implementation (PyLibMCCache)

[Django]

#35498: Race-condition using Django pylibmc implementation (PyLibMCCache)
-+-
   Reporter:  Bruno  |  Owner:  nobody
  Mayer Paixão   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Core   |Version:  3.2
  (Cache system) |   Keywords:  cache pylibmc
   Severity:  Normal |  thread-safe
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The Django cache implementation for the pylibmc library (PyLibMCCache)
 uses the default client, without pooling connections. This library is not
 thread-safe by default. Although Django stores the cache connections using
 a thread-safe implementation, a race condition can occur in some
 scenarios.

 I created an example project to reproduce the problem:
 [https://github.com/brunomrpx/django-pylibmc-thread-unsafe-example]

 The scenario is the following:
 - A Django application with uWSGI and threads enabled, using the
 FetchFromCacheMiddleware and UpdateCacheMiddleware middlewares
 - A route that receives a key to be stored in cache, which is requested by
 multiple users.
   - If the key doesn't exist in cache, it is stored using the key as the
 value.
   - If the key exists in cache, the system checks if the key used is the
 same as the returned value.
   - If the key and value are not the same, a key mismatch occurs.

 I'm able to receive a cached view as a result of accessing the cache using
 a user's key. It also results in users accessing keys stored by other
 users in a production application. At the end of the README in the example
 repository there are some suggestions to solve the problem, maybe using
 the ThreadMappedPool ([https://github.com/brunomrpx/django-pylibmc-thread-
 unsafe-example/blob/main/cache/cache.py]) would be a good approach.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018fea68f643-3fb83a4a-ec03-42cd-8ce6-c728a7099a9d-00%40eu-central-1.amazonses.com.

Re: [Django] #35494: Testing Class-based Views Clarification

[Django]

#35494: Testing Class-based Views Clarification
-+-
 Reporter:  Matthew Pava |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  test cbv | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Matthew Pava):

 I got confused with the `RequestFactory` object. Of course, it makes sense
 that would return a request. I got so focused on using `self.client.get`,
 which does return a response if my understanding is correct.

 Even so, the example is inconsistent with the other examples on the
 webpage, which use `self.client.get` instead of `RequestFactory.get`.

 I used `self.client.get` in my test, and it worked just as well.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018fe8af9c12-ad45a37c-a54c-4c39-8f8b-d8c7b8fdcb17-00%40eu-central-1.amazonses.com.

[Django] #35497: Long email address causes crash when generating a message

[Django]

#35497: Long email address causes crash when generating a message
-+
   Reporter:  Alexandru Chirila  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core (Mail)|Version:  5.0
   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  |
-+
 Trying to generate an email message that has a long recipient address and
 non-ASCII characters causes a crash.

 How to reproduce:

 {{{
 EmailMessage(to=["ţēśţ." * 6 + "@example.com"]).message()
 }}}

 Looking for an existing issue I have found #31784. It seems like the issue
 there was only fixed for long names and long addresses.

 

 Version info:

 - Django: 5.0.6
 - Python: 3.12.3

 

 Full log:

 {{{#!python
 In [2]: from django.core.mail import EmailMessage

 In [3]: EmailMessage(to=["ţēśţ." * 6 + "@example.com"]).message()
 ---
 UnicodeEncodeErrorTraceback (most recent call
 last)
 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:64, in
 forbid_multi_line_headers(name, val, encoding)
  63 try:
 ---> 64 val.encode("ascii")
  65 except UnicodeEncodeError:

 UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3:
 ordinal not in range(128)

 During handling of the above exception, another exception occurred:

 ValueErrorTraceback (most recent call
 last)
 Cell In[3], line 1
 > 1 EmailMessage(to=["ţēśţ." * 6 + "@example.com"]).message()

 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:267,
 in EmailMessage.message(self)
 265 msg["Subject"] = self.subject
 266 msg["From"] = self.extra_headers.get("From", self.from_email)
 --> 267 self._set_list_header_if_not_empty(msg, "To", self.to)
 268 self._set_list_header_if_not_empty(msg, "Cc", self.cc)
 269 self._set_list_header_if_not_empty(msg, "Reply-To", self.reply_to)

 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:432,
 in EmailMessage._set_list_header_if_not_empty(self, msg, header, values)
 430 except KeyError:
 431 value = ", ".join(str(v) for v in values)
 --> 432 msg[header] = value

 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:165,
 in SafeMIMEText.__setitem__(self, name, val)
 164 def __setitem__(self, name, val):
 --> 165 name, val = forbid_multi_line_headers(name, val,
 self.encoding)
 166 MIMEText.__setitem__(self, name, val)

 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:67, in
 forbid_multi_line_headers(name, val, encoding)
  65 except UnicodeEncodeError:
  66 if name.lower() in ADDRESS_HEADERS:
 ---> 67 val = ", ".join(
  68 sanitize_address(addr, encoding) for addr in
 getaddresses((val,))
  69 )
  70 else:
  71 val = Header(val, encoding).encode()

 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:68, in
 (.0)
  65 except UnicodeEncodeError:
  66 if name.lower() in ADDRESS_HEADERS:
  67 val = ", ".join(
 ---> 68 sanitize_address(addr, encoding) for addr in
 getaddresses((val,))
  69 )
  70 else:
  71 val = Header(val, encoding).encode()

 File .venv/lib/python3.12/site-packages/django/core/mail/message.py:120,
 in sanitize_address(addr, encoding)
 117 localpart = Header(localpart, encoding).encode()
 118 domain = punycode(domain)
 --> 120 parsed_address = Address(username=localpart, domain=domain)
 121 return formataddr((nm, parsed_address.addr_spec))

 File ~/.pyenv/versions/3.12.3/lib/python3.12/email/headerregistry.py:33,
 in Address.__init__(self, display_name, username, domain, addr_spec)
  31 inputs = ''.join(filter(None, (display_name, username, domain,
 addr_spec)))
  32 if '\r' in inputs or '\n' in inputs:
 ---> 33 raise ValueError("invalid arguments; address parts cannot
 contain CR or LF")
  35 # This clause with its potential 'raise' may only happen when an
  36 # application program creates an Address object using an addr_spec
  37 # keyword.  The email library code itself must always supply
 username
  38 # and domain.
  39 if addr_spec is not None:

 ValueError: invalid arguments; address parts cannot contain CR or LF
 }}}
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this 

Re: [Django] #35496: ASGI Connection Leakage during Exception Logging

[Django]

#35496: ASGI Connection Leakage during Exception Logging
-+--
 Reporter:  mietma   |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  4.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):

 * resolution:   => invalid
 * status:  new => closed


Old description:

> Hi,
>
> I am having trouble with Django ASGI leaving idle connections if
> exceptions are thrown. I narrowed it down to the logging of the
> exceptions.
> The 'ExceptionReporter' opens new connections during the
> 'get_traceback_text()' method, which are then not closed.
> I made a workaround by implementing a custom ExceptionReporter which
> closes connections afterwards.
>
> class CustomExceptionReporter(ExceptionReporter):
> def get_traceback_text(self):
> res = super().get_traceback_text()
> close_old_connections()
> return res
>
> Is my approach correct or am I destroying something else?
>
> Best regards,
> Matthias

New description:

 Hi,

 I am having trouble with Django ASGI leaving idle connections if
 exceptions are thrown. I narrowed it down to the logging of the
 exceptions.
 The 'ExceptionReporter' opens new connections during the
 'get_traceback_text()' method, which are then not closed.
 I made a workaround by implementing a custom ExceptionReporter which
 closes connections afterwards.

 {{{
 class CustomExceptionReporter(ExceptionReporter):
 def get_traceback_text(self):
 res = super().get_traceback_text()
 close_old_connections()
 return res
 }}}

 Is my approach correct or am I destroying something else?

 Best regards,
 Matthias

--
Comment:

 Thanks for the ticket, however it's a support question and Trac is not a
 support channel, check out TicketClosingReasons/UseSupportChannels.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018fe7f72ad7-4f01ab88-7a2d-45a8-9926-5cbaad3e651b-00%40eu-central-1.amazonses.com.

Re: [Django] #35494: Testing Class-based Views Clarification

[Django]

#35494: Testing Class-based Views Clarification
-+-
 Reporter:  Matthew Pava |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  test cbv | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Mariusz Felisiak (added)
 * resolution:   => invalid
 * status:  new => closed

Comment:

 > The `RequestFactory().get()` method returns a response, and not a
 request.

 That's not true, it generates a request instances.

 > Lastly, the response object is not a request object that you would pass
 into the view.setup function.

 Why not?

 As far as I'm aware, the current examples work fine.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018fe7835075-2e1deaef-aece-40d0-9540-5446e90ad5b0-00%40eu-central-1.amazonses.com.

[Django] #35496: ASGI Connection Leakage during Exception Logging

[Django]

#35496: ASGI Connection Leakage during Exception Logging
---+
   Reporter:  mietma   |  Owner:  (none)
   Type:  Bug  | Status:  new
  Component:  Error reporting  |Version:  4.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|
---+
 Hi,

 I am having trouble with Django ASGI leaving idle connections if
 exceptions are thrown. I narrowed it down to the logging of the
 exceptions.
 The 'ExceptionReporter' opens new connections during the
 'get_traceback_text()' method, which are then not closed.
 I made a workaround by implementing a custom ExceptionReporter which
 closes connections afterwards.

 class CustomExceptionReporter(ExceptionReporter):
 def get_traceback_text(self):
 res = super().get_traceback_text()
 close_old_connections()
 return res

 Is my approach correct or am I destroying something else?

 Best regards,
 Matthias
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018fe7796422-f86117b1-5b0c-4178-84dc-c13467017782-00%40eu-central-1.amazonses.com.