Skip to content

SMTP Alert Hardening Configuration

Ticket #148: SMTP Alert Hardening Configuration
Type: Reliability / Security / Observability
Affected Component: code_source_simule/pipeline.py, tests/test_pipeline.py, README.md, docs/features/chapter3.md, docs/fr/features/chapter3.md


1. Context

Email alerts were already present in the ETL pipeline, but SMTP runtime behavior needed hardening for production operations: explicit transport mode, bounded timeout, and clearer diagnostics while keeping fail-open behavior.

2. Objective

Strengthen SMTP alert delivery without breaking existing alert flows:

  • keep environment-variable-only configuration for SMTP secrets
  • support explicit transport mode (starttls, ssl, none)
  • add configurable timeout (SMTP_TIMEOUT_SECONDS)
  • keep fail-open behavior with diagnosable structured events

3. Implementation delivered

  • Added SMTP config parsing and validation helper in pipeline.py
  • Added explicit transport selection:
  • starttls: smtplib.SMTP + starttls()
  • ssl: smtplib.SMTP_SSL
  • none: plain smtplib.SMTP
  • Added configurable timeout with safe default (10s)
  • Added structured events for missing/invalid SMTP config and send failures/successes
  • Preserved existing quota and missing-price alert subjects
  • Propagated logger into alert call sites for operational diagnostics

4. Validation

  • Focused pipeline tests passed after TDD implementation
  • Full repository suite passed (54 passed)
  • Global coverage recalculated: 95%
  • code_source_simule/pipeline.py coverage recalculated: 87%
  • No regression on quota-aware modes and existing alert triggers

5. Production validation (2026-03-29)

  • SMTP credentials (WHC mail server) injected into production .env on Hostinger VPS
  • Simulated quota alert triggered via docker compose exec
  • Email successfully received
  • End-to-end chain confirmed: application → WHC SMTP → inbox delivery

6. Operational outcome

Operators now have explicit SMTP runtime controls and clearer failure diagnostics, while the ETL remains fail-open and does not block business processing when email delivery fails.