C1.2c Preserve Reply-To and copy recipients through Relay mail transport

Open
  • Is something wrong?
#415 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
django, python
Domain
backend

Research direction

Start with community_base/mail/relay.py and community_base/mail/backends/relay.py: RelayMailClient.send() builds the HTTP payload but drops reply_to, cc, and bcc that send() already persists in EmailDelivery.transport_options. Add wire-capture regression tests in tests/mail/test_relay_backend.py, then map the validated options into Relay native fields, rejecting multiple Reply-To values with a sanitized RelayMailError before any request. Done means the captured POST /api/transactional/send JSON preserves the options in their native shapes, the multi-Reply-To case makes zero HTTP requests, and the package suite plus quality gates pass.

Written by the indexing model from the issue text.

Description

bug

Title: C1.2c Preserve Reply-To and copy recipients through Relay mail transport
Repository: community-base
Depends on: C1.2a, C1.2b (both done)
Freeze required: no

Goal

Preserve the recipient routing options already validated and stored by durable mail when the selected backend is Relay. AISHL adoption issue AI-Shipping-Labs/website#2006 requires welcome replies, alternate recipients, and hidden staff copies to survive the transport change.

Confirmed regression

At package v0.5.33, send() validates and persists reply_to, cc, and bcc in EmailDelivery.transport_options, but RelayMailClient.send() omits all three from its HTTP payload. Offline capture of the actual transport request reproduces the omission. No live mail or production data is needed.

Read first

  • AGENTS.md, docs/PROCESS.md, docs/04-quality-gates.md.
  • docs/01-decisions.md, docs/02-architecture.md.
  • docs/03-playbooks.md P15 and P16.
  • community_base/mail/service.py, community_base/mail/relay.py.
  • community_base/mail/backends/relay.py, community_base/mail/backends/ses_local.py.
  • tests/mail/test_relay_backend.py, tests/mail/test_ses_local.py.
  • docs/plan/phase-1.md, docs/plan/STATUS.md.

Steps

  1. Add the C1.2c plan entry and synchronize its status before implementation; keep the fix on its isolated package branch.
  2. Add capture-wire regression tests and show they fail against the omitted-field implementation.
  3. Explicitly map validated transport options into Relay native fields: singleton reply_to as one string; cc and bcc as lists. Omit absent or empty options.
  4. Reject more than one Reply-To address before any HTTP request with a sanitized, nonretryable RelayMailError; do not truncate, silently discard, or put addresses in the error.
  5. Keep existing envelope construction and validation. Never merge the complete transport_options object into the payload. SES-only configuration_set and unsupported entries cannot become Relay fields or override core envelope fields.
  6. Document supported Relay option shapes and the multi-Reply-To limitation. Retain SES transport behavior and existing sender, context, idempotency, suppression, and response handling.
  7. Run package tests and quality gates, then validate both consuming sites against this package change using disposable checkouts and P16. Follow the package PR process and P15 release-before-pin sequence.

Verification

  • Capture the actual POST /api/transactional/send JSON through the injected transport; assert exact option values and native shapes together with unchanged core envelope fields.
  • Exercise singleton Reply-To, CC, BCC, combined options, omitted/empty options, SES-only configuration set, and unsupported multiple Reply-To. The last case must record zero HTTP requests.
  • Run timeout 900 uv run pytest tests/mail and the package suite with all extras installed; record collected counts and results. Run every applicable gate in docs/04-quality-gates.md, each command bounded by timeout 900, plus uv run python scripts/plan.py check.
  • Record package, AISHL, and DTC results separately. Consumer validation must exercise the changed package, identify its exact revision, and distinguish baseline failures from new failures under P16. AISHL full local Django runs remain prohibited; use its affected-test selection or authoritative cross-repository CI.
  • No real email, production credentials, or production database is required. This issue changes the shared package only; the AISHL core Django email backend Reply-To correction is a companion site task.

Done when

  • Captured Relay JSON contains singleton reply_to as a string and preserves cc and bcc as lists, including the combined-options case.
  • Missing or empty recipient options leave the ordinary send payload unchanged.
  • Only supported recipient options are copied; SES-only configuration sets and unrelated option entries never become Relay fields or override recipient, template, version, context, sender, or idempotency data.
  • Multiple Reply-To values fail explicitly with a sanitized, nonretryable error before the transport is called.
  • Existing SES option forwarding and normal Relay behavior remain covered and pass.
  • Package suite and applicable quality gates pass with collected counts recorded.
  • AISHL and DTC validation against the changed package are recorded separately; any blocked validation is explicit and does not count as passing.
  • Documentation and plan status match the implementation.
  • Reviewed package PR is merged and a new immutable release exists before consumer pin changes.

Docs

  • community_base/mail/README.md.
  • docs/plan/phase-1.md, generated docs/plan/STATUS.md.
  • CHANGELOG.md and package version metadata during the approved P15 release.
Dominant language
Python
Stars
0
Forks
0
Avg merge
1h 5m
Merged PRs (30d)
3

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataTalksClub/community-base

All issues in DataTalksClub/community-base

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.