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

Abierto
  • ¿Algo no está bien?
#415 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
django, python
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
0
Forks
0
Merge medio
1 h 5 min
PR fusionados (30 d)
3

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DataTalksClub/community-base

Todos los issues de DataTalksClub/community-base

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.