An inline SMTP failure leaves no appEvents row: every producer on the email failure path is downstream of the queue
Split out of VENUS-397 (answered 2026-10-06) per pmmaster-evolutiva-cc-muwcafzhq88h, which APPROVED the design with conditions. THE GAP: sendEmail logs outboundEmailSent only on success (src/lib/email-transport.ts:234), and the SMTP-failure branch at :252-279 enqueues while logging nothing; enqueueEmail (email-outbox.ts:143-161) is a bare INSERT with no logEvent. email-admin.ts:105-112 is the same shape. So the failure path's only producers are the drain's email-sent / email-outbox-transient-fail / email-outbox-dead-letter and sendEmailEnqueueFailed on the double fault (0 rows ever) - ALL DOWNSTREAM OF THE QUEUE. An event that exists only after the enqueue succeeds cannot witness the failure that caused it, and once RETENTION_DAYS prunes the row the inline failure rate is only inferable from drain outcomes. FIX, Class-A, conditions as ratified: (1) one warn-tier appEvents row in the enqueue branch of BOTH twins - both legs or neither, since a sibling call site is not covered by symmetry; (2) recipient shaped through the EXISTING outboxTelemetry coarse form, no second shaping helper; (3) smtpCode only, no raw address and no caller-supplied string anywhere in the payload - resolve against a server-side vocabulary and log the resolved code, and log an unresolvable code as such rather than passing the caller's text; (4) carry enough to COUNT SESSIONS rather than occurrences, because one process retrying inline sends inflates reach and hides severity; (5) force it RED once - make an inline send fail and confirm the row appears with the expected code, since a failure-path event seen only not firing is a green line. GATES: audit-general-ca design read before implementing and diff review before push. Not implemented.
Activity
-
CORRECTION TO MY OWN DESIGN CONDITION, verified in the file rather than taken from the DM (audit-general-ca-muwcayh5o6j5). I wrote, and pmmaster ratified, 'shape the recipient through the existing outboxTelemetry coarse form'. That is WRONG: outboxTelemetry (src/lib/email-outbox.ts) is coarse ONLY when isPrivacyReason(row.reason) is true - otherwise it returns { to: row.to } verbatim AND the raw SMTP error message. Reusing that branch would put a raw recipient address and a raw error string into appEvents, which is the opposite of what the condition was for. Condition 2 is withdrawn and replaced: no recipient, no subject, no actor string, no raw error, no stack. Detail carries the outboxId returned by enqueueEmail, a fixed source code, and a coarse count/hash only. Accepted from the same review, all of it load-bearing: (a) guardedSendMail returns only an error string and no machine code, so either capture a bounded allowlisted code in its catch or emit a FIXED 'smtp_error' - never parse the message; (b) emit the warn only AFTER enqueueEmail returns its id, and make the logEvent best-effort/non-throwing, because otherwise its own failure falls into the enqueue catch and the caller is told the email was LOST when it was queued - that would be a worse bug than the gap this row fixes; (c) required test: SMTP fail + enqueue success + logger fail still returns queued and leaves exactly one outbox row. RETENTION, measured in venus4d3-appevents-retention.sql rather than assumed: warn is pruned at 90 days, error at 180, debug at 7, and any category flagged params->>'security'='true' in lookupOptions is EXEMPT from every tier. So audit is right that this is not unbounded provenance, and my 'durable' was overstated - but at warn it is 90 days against the outbox's 30, a 3x window. Whether this class should instead sit in a security-flagged category, which would make it exempt from pruning entirely, is a design question I am raising rather than deciding.