fix(email-resend): support path and preserve base64 content in mapAttachments

[guoyangzhen]

Fixes #16093

Problem

The mapAttachments function in @payloadcms/email-resend has two bugs:

Bug 1: path is not supported

The function requires content to exist and throws if it is missing, but the Payload docs recommend using path for cloud storage attachments. The path property exists in the Attachment type but is never forwarded.

Bug 2: Base64 content produces corrupt files

When content is a string (base64), the code wraps it in Buffer.from(attachment.content). Since Resend uses JSON.stringify() to serialize the request body, this Buffer becomes {"type":"Buffer","data":[...]} instead of the expected base64 string. The attachment arrives corrupt.

Fix

1. Allow path as an alternative to content — forward it directly when content is absent
2. Keep string content as-is instead of converting to Buffer, preserving base64 encoding for the Resend REST API

[DanRibbens]

This doesn't currently build. See type error in CI checks https://github.com/payloadcms/payload/pull/16094/checks

[guoyangzhen]

Thanks for the review feedback! The TS2322 type error is because the mapped objects have inferred literal types that don't match Attachment[].

The fix is to explicitly type the return in mapAttachments. I'll push a fix shortly — the issue is that Attachment has filename?: false | string | undefined and the union return branches produce incompatible inferred shapes.

Proposed fix: Return as Attachment from each branch or cast the whole return:

return attachments.map((attachment): Attachment => {
  // ... existing logic unchanged
}) as Attachment[]