feat: HTML email delivery for cron jobs and send_message - #34603
Conversation
Three coordinated changes so HTML content flows end-to-end:
cron/scheduler.py: detect HTML in job output, skip plain-text wrapper
to preserve the doctype, allow cron jobs to set email subject via
job name (with {date} substitution), and forward email_subject
through both live adapter and standalone send paths.
gateway/platforms/email.py: when content starts with <!doctype html
or <html, send as multipart/alternative with plain-text fallback.
Strip <style> and <head> blocks in the fallback. Respect explicit
subject from metadata. Fresh HTML emails omit threading headers
so they appear as their own thread in Gmail.
tools/send_message_tool.py: same HTML detection + multipart/alternative
logic in the standalone SMTP path. Strip preamble text before the
doctype. Accept optional email_subject parameter.
alt-glitch
added
type/feature
|
Thanks for adding the subject plumbing here — this is a big improvement for outbound mail. One thing I filed separately as #46947: the cron |
Yes, that would be great. Also thanks for filing the bug report! |
teknium1
left a comment
teknium1
left a comment
There was a problem hiding this comment.
Thanks for the HTML-email delivery work. The underlying behavior is still present on current main, but this branch predates the email-plugin migration and needs a targeted salvage.
Problems
gateway/platforms/email.pyin this PR was moved by5600105478ffde29d7566b45421b100eaa29c4ef; current outbound code isplugins/platforms/email/adapter.py:893-962and:1190-1230. Currenttools/send_message_tool.py:1067-1068routes standalone email through the registry, so the proposed direct_send_emailwiring no longer reaches the live sender.- The diff adds an internal
email_subjectargument but does not add a field toSEND_MESSAGE_SCHEMA(tools/send_message_tool.py:197-234) or extract it in_handle_send(:354-460), sosend_messagecallers cannot supply the claimed subject. - The PR adds no tests; current
tests/gateway/test_email.py:845-856still asserts the problematic fresh-recipient default.
Suggested changes
- Port both live and standalone behavior to
plugins/platforms/email/adapter.py, retaining registry routing. - Add and propagate a schema-level
email_subject, then cover HTML MIME parts, explicit subject/fresh-thread behavior, and cron delivery with focused tests.
Automated hermes-sweeper review.
| @@ -554,7 +554,7 @@ async def _send_via_adapter( | |||
| } | |||
There was a problem hiding this comment.
This only adds an internal parameter: the PR does not add email_subject to SEND_MESSAGE_SCHEMA or extract it in _handle_send, so send_message callers cannot provide the subject described in the PR. Please wire the public argument through the actual send path.
teknium1
added
sweeper:risk-message-delivery
|
Overlap note (2026-08-03): this PR addresses the same topic (HTML email delivery). PR #73294 (swissly) consolidates Markdown-to-HTML rendering for ALL 4 send paths + allowlist sanitizer + 20 tests, and was just rebased onto current main (commit 9529ee30). Please review #73294 for consolidation rather than duplicating send-path fixes. |
5 participants
Three coordinated changes so HTML content flows end-to-end through cron delivery and send_message:
{date}substitution), and forwardemail_subjectthrough both live adapter and standalone send paths.<!doctype htmlor<html, send asmultipart/alternativewith plain-text fallback. Strip<style>and<head>blocks in the fallback. Respect explicit subject from metadata. Fresh HTML emails omit threading headers so they appear as their own thread in Gmail.multipart/alternativelogic in the standalone SMTP path. Strip preamble text before the doctype. Accept optionalemail_subjectparameter.