fix(Resend): send attachments via per-message endpoint

[lohanidamodar]

Symptom

Sending an email with attachments via the Resend adapter currently results in the recipient receiving the email without the attachments. The attachments are silently dropped.

Root cause

The adapter has always posted to Resend's batch endpoint POST /emails/batch for every send. That endpoint only accepts from, to, subject, html, text, cc, bcc, reply_to, headers, scheduled_at, tags, etc. — it does not support attachments or scheduled_at and silently ignores them. See Send batch emails — the docs explicitly call this out:

The attachments and scheduled_at fields are not supported yet.

Resend's single-send endpoint POST /emails does support attachments. See Send email.

Fix

Resend::process() now branches on whether the message carries attachments:

• No attachments (existing behavior, preserved): one batch POST to /emails/batch with all recipients in one request — throughput unchanged for the common case.
• With attachments (new): one POST per recipient to /emails, each with the attachments array (filename / content / content_type) embedded. Per-recipient outcomes are aggregated into the same Response shape the batch path returns, so partial success is reported correctly.

The per-email size limit is also raised to 40 MB to match Resend's documented single-send cap.

Test plan

• composer lint (Pint, PSR-12) passes
• composer analyse (PHPStan level 6) passes
• New ResendRoutingTest (4 tests, 25 assertions) passes — stubs request() and asserts:
  • no-attachment send hits /emails/batch once with all recipients in the body
  • attachment send hits /emails once per recipient with the attachments array shaped correctly
  • partial failure across recipients aggregates deliveredTo and per-recipient status/error
  • oversized payload (> 40 MB) throws before any HTTP call
• Manual end-to-end against Resend (out of scope for CI; existing integration tests in ResendTest continue to require RESEND_API_KEY and a verified test address)

[greptile-apps]

Greptile Summary

This PR fixes the Resend adapter silently dropping attachments by routing to the correct API endpoint depending on whether attachments are present. The attachment size cap is also raised from 25 MB to 40 MB to match Resend's documented single-send limit.

• Routing logic: process() now branches — no attachments sends a single POST /emails/batch (existing behavior, unchanged), while the presence of attachments switches to one POST /emails call per recipient via the new sendIndividually() method.
• Error handling: extractErrorMessage() is extracted as a shared helper; the batch 200 path gains an is_array() guard on the response body; partial per-recipient failures are aggregated into the same Response shape.
• Tests: A new ResendRoutingTest with a ResendStub covers batch routing, per-recipient routing, partial failure aggregation, and oversized-attachment rejection without requiring a live API key.

Confidence Score: 4/5

Safe to merge; the core routing logic is correct and well-tested, with the no-attachment batch path left untouched.

The attachment-routing fix is straightforward and the new tests validate all four key scenarios. The only open question is that getMaxMessagesPerRequest() still caps at 100, so a large recipient list with attachments triggers up to 100 sequential HTTP calls with no rate-limit handling — a practical concern for high-volume senders but not a correctness defect in the changed code.

The sequential-request loop in sendIndividually inside Resend.php deserves a second look if this adapter will be used with large recipient lists and attachments.

Important Files Changed

Filename	Overview
src/Utopia/Messaging/Adapter/Email/Resend.php	Introduces attachment-aware routing: posts to /emails/batch when there are no attachments, and makes one /emails call per recipient when attachments are present. Logic is correct; the per-recipient loop makes up to 100 sequential HTTP calls (the existing batch cap) with no rate limiting.
tests/Messaging/Adapter/Email/ResendRoutingTest.php	New test class with a ResendStub that overrides request() to capture calls and return canned responses. Covers the four main cases: batch routing, per-recipient routing, partial failure aggregation, and oversized-attachment rejection. Assertions are accurate.
tests/Messaging/Adapter/Email/ResendTest.php	Only change is updating the oversized-attachment threshold from 25 MB to 40 MB to match the new MAX_ATTACHMENT_BYTES constant.

Comments Outside Diff (1)

1. src/Utopia/Messaging/Adapter/Email/Resend.php, line 29-31 (link)

   getMaxMessagesPerRequest() still allows 100 recipients for the attachment path

   getMaxMessagesPerRequest() returns 100, so the adapter's caller can legitimately pass up to 100 recipients in a single process() call. With attachments present, sendIndividually fires one sequential HTTP request per recipient, meaning up to 100 blocking Resend API calls per process() invocation. This has no rate-limit back-off, no concurrency cap, and no partial-resume on network failure mid-loop. For large recipient lists with attachments this will be noticeably slow and is likely to trigger Resend's per-second rate limit. Lowering the cap (e.g. to 10) when attachments are present, or adding retry/delay logic, would make this path safer in production.

_{Reviews (1): Last reviewed commit: "fix(Resend): send attachments via per-me..." | Re-trigger Greptile}