03-Jun-2026 — render outbound replies; perf(email-composer): faster drafts and sent lists ref #278

build 666 — commit be5d942

📖 New to this feature? See Setting up a Gmail inbox for committee replies for the step-by-step setup guide.

perf(email-composer): faster drafts and sent-emails lists (ref #278)

The Email Composer's Drafts and Sent lists now open faster. Until now, opening either list pulled the full contents of every saved email - recipients, attachments and the whole message - just to draw the row. The list now asks the server only for the bits it needs to show, and the full email is fetched the moment you open it.

At a glance

• Faster Drafts and Sent lists. Especially noticeable when you have many emails saved.
• No behaviour change. Opening, restoring, saving, sending and deleting an email work exactly as before.
• Less work on both sides of the request. Less data over the wire, less memory in the browser.

Where it shows up

Open Admin > Email Composer (/admin/email-composer) and look at the Drafts and Sent tabs. Both lists use the lighter request now. Anyone who has built up a large pile of saved drafts or sent emails should feel the difference straight away.

What stays the same

• Every saved email is still there, in the same order, with the same details on the row: title, who saved it, when it was last saved or sent, and the recipient count for sent ones.
• Opening a draft restores it in full, ready to keep editing.
• Opening a sent email shows everything that went out.
• Sharing settings, the drafts vs sent split and the recipient counts are unchanged.

How to try it out

1. Open the Email Composer with a number of saved drafts and sent emails.
2. Watch the Drafts and Sent lists open.
3. Open one of the entries and confirm it restores fully with recipients, attachments and content.
4. Save a draft and send a test email; confirm both appear in the lists with the right details.

In short

The Email Composer's Drafts and Sent lists load faster because the server now sends only what is needed to draw the rows. Opening an email still gets you everything.

fix(inbox): render outbound replies in conversation view (ref #278)

Outbound replies sent from the inbox were being recorded locally with bodyHtml and bodyText both null, even though the transactional email request already carried the HTML that had just been sent to the recipient. The inbox renderer falls back to "(empty message body)" when both body fields are null, which made Nick's own sent reply appear blank in the conversation view.

What changed:

• Store emailRequest.htmlContent as bodyHtml when recording the outbound InboxMessage created by performInboxReplyWriteback.
• Keep bodyText null because the EmailRequest shape does not currently carry a plain-text version of the rendered message.
• Continue writing a sent copy into Gmail when the mailbox connection has a refresh token.
• When a stored Gmail message has no body and no external Gmail id, look it up by its RFC Message-ID using Gmail's rfc822msgid search before hydrating the body and attachments.
• Persist the discovered Gmail externalId alongside the hydrated body so future thread opens do not repeat the lookup.