You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Django backend retains automatically opened client after send failure #38
EmailBackend.send_messages closes a client it creates only when every batch succeeds. If send_batch raises, or a response contains a per-message failure, the backend retains the open client even when the caller did not explicitly open it. This affects both fail_silently settings.
Close automatically created clients on failure as well as success. Preserve an explicitly opened/caller-owned connection for reuse. Keep exception and fail_silently behavior unchanged.
Environment
postmark-python 0.4.0 / current main
Python 3.12, Django 5.2, macOS
Additional context
The send loop and close call can be wrapped in try/finally inside the existing exception-handling boundary. I plan to cover transport errors and API response failures, both ownership modes and both fail_silently settings. Local mocked transport only; no actual emails sent. AI assistance: OpenAI Codex.
Hi @Kayvan-Zahiri ! Thank you for such a clear report. Your reproduction was exactly what I needed... and I confirmed on main that a client the backend opens itself is left attached after a failed send, especially important in the in the common 1send_mail()1 path... every call builds a new backend, so I appreciate you ending the leaking HTTP client(s).
Your fix in #39 looks like the right one. I'm reviewing it there now and I'll follow up on that PR.
Activity
gregsvo commentedon Oct 28, 2026
Hi @Kayvan-Zahiri ! Thank you for such a clear report. Your reproduction was exactly what I needed... and I confirmed on main that a client the backend opens itself is left attached after a failed send, especially important in the in the common 1send_mail()1 path... every call builds a new backend, so I appreciate you ending the leaking HTTP client(s).
Your fix in #39 looks like the right one. I'm reviewing it there now and I'll follow up on that PR.