Repository navigation
fix(django): close automatically opened client after send failures - #39
Conversation
|
Excellent. Good catch. I'm pulling/testing now. Will merge if no issue. |
|
Excellent work here, @Kayvan-Zahiri. I checked it out all tests pass. lint and mypy are clean, all good. I did find one small edge case: if Could you also mark the PR Ready for review? Our CI needs a maintainer to approve the first run on a fork, and I'll do that as soon as it's ready. This should go out in the next release, and I'll credit you in the release notes. Thanks again! |
|
Marked ready. Thanks for testing it, and good call on letting the original send error win over a close() failure. |
If client.close() raised while cleaning up after a failed send, the close error replaced the original one for the caller and for on_exception. Log the close error and keep the send error; a close error after a successful send is still raised, as before.
|
Thanks again! Merged. |
Problem and change
Django's Postmark backend leaves an automatically opened client attached after
send_batchraises or returns a failed message. The close call is only reached after every batch succeeds.Put the batch loop inside
try/finallyso clients opened bysend_messagesare closed on failure too. Keep this cleanup inside the existing exception-handling boundary sofail_silently, error signals, partial success counts, and caller-owned connection reuse remain intact. Add an Unreleased changelog entry.Fixes #38.
Validation
fail_silentlyvalues, and automatically opened versus caller-owned clients.pytest --cov=postmark --cov-report=term --cov-fail-under=85— 462 passed, 96.32% coverage.pre-commit run --all-files— all applicable hooks pass, including Poetry metadata/lock consistency, pinned Ruff/MyPy, codespell, Bandit, and secret scanning.git diff --checkpasses. No unrelated file changes.AI assistance: OpenAI Codex investigated, implemented, tested, and prepared this draft. Human verification is not claimed.