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

Aperta
#415 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
django, python
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Python
Stelle
0
Fork
0
Merge medio
1h 7m
PR unite (30g)
5

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DataTalksClub/community-base

Tutte le issue di DataTalksClub/community-base

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.