docs(campaign): distinguish worker process evidence

This commit is contained in:
2026-07-22 18:26:42 +02:00
parent 2fa91bb943
commit 6fda123fc3
3 changed files with 39 additions and 18 deletions

View File

@@ -107,15 +107,20 @@ bed where possible:
For the maintained loopback baseline, run
`dev/mail-testbed/run_campaign_acceptance.py`. It proves the public Campaign
path for SMTP acceptance, IMAP append, repeat-send blocking, an SMTP connection
failure before transmission, an explicit SMTP authentication rejection, and an
IMAP authentication rejection after SMTP acceptance. Its evidence is an
allowlisted classification/count projection; raw provider diagnostics and
transport/account identifiers are deliberately excluded.
failure before transmission, an explicit SMTP authentication rejection, an
explicit temporary `451` response after DATA, partial RCPT refusal, a
connection loss after complete DATA, and an IMAP authentication rejection
after SMTP acceptance. Its evidence is an allowlisted classification/count
projection; raw provider diagnostics and transport/account identifiers are
deliberately excluded.
The runner does not simulate a connection loss after SMTP DATA and does not
restart a real worker. Keep those two checklist items open until a controlled
fault proxy/target provider and supervised worker environment can produce the
corresponding `outcome_unknown`, restart, retry, and reconciliation evidence.
The runner also terminates a dedicated OS process executing the registered
Campaign send task after complete DATA, then invokes the task in a fresh
process. The unfinished durable attempt must become `outcome_unknown` and the
endpoint must observe no second connection or DATA transaction. This covers
the worker task/process boundary. It does not cover Redis/Celery delivery,
acknowledgement, broker redelivery, or daemon supervision; repeat the drill in
that infrastructure before approving a production worker deployment.
## Reporting Checks