mirror of
https://github.com/karatektus/pl_mail.git
synced 2026-10-25 10:04:18 +00:00
Paul LütznerandClaude Opus 5
7065d2a192
A send is held for ten seconds so it can be called off. The browser marked the end of the CANCEL window — eight seconds — by asking the server to tidy up, and that answer carried "Message sent." So the confirmation preceded the attempt by two seconds, every time, for everybody. And nothing ever corrected it. All three senders turn a failure into a bare `false`, which SendMessageHandler treated as handled: no retry, no failed-transport row, nothing. SmtpMailSender goes further and binds the transport exception without using it, so a hard SMTP rejection left zero trace anywhere in the system. The user was told the mail had gone, and it had not. Now the eight-second mark only tidies, and the outcome is published from the worker when there is one — success or failure, over the live-updates stream that is already there. The failure toast is the case that had no surface at all. It publishes RENDERED html, because the alternative is a toast built in JavaScript, which is a second copy of _toast.html.twig drifting from the first. Best effort, and honestly so: with the hub down there is no toast, which is a confirmation missing rather than a confirmation that lies. WHAT THE E2E SUITE CAN AND CANNOT SHOW It cannot show the toast. The test app runs MESSENGER_TRANSPORT_DSN=in-memory://, so a send dispatched by a browser request is discarded when the request ends and no worker can pick it up — which also means those specs were only ever asserting the premature claim. They now pin the half that was wrong: that nothing announces an outcome it does not have. The publishing side is covered by SendOutcomeNotifierTest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>