Three sharp edges in the SES event path: no config-set update, a silent ARN refusal, and DELIVERY ingested then dropped Issue open
Migrated from github.com/carlosframework/platform issue #270, opened 2026-08-23. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: EnsureConfigSet has no update path, so changing the SNS topic ARN leaves config sets publishing to the old topic.
---
Found while wiring SES event ingest (#240 follow-up). None is blocking today; all three get worse with adoption.
1. EnsureConfigSet has no update path, making the topic ARN one-way
It swallows AlreadyExists on CreateConfigurationSetEventDestination and never updates an existing destination. So if CARLOS_MAIL_SNS_TOPIC_ARN is ever changed, re-running the domain walk leaves every existing configuration set publishing to the old topic — silently, and with the walk reporting success.
Harmless right now because no carlos-* configuration set exists yet. That is exactly why it is worth fixing now: the moment the first one is created, the choice of ARN becomes effectively permanent, and the failure mode is "events stopped arriving and nothing said so".
2. The TopicArn refusal writes no log line
handleSESEvents rejects an unrecognised topic with jsonError and no log.Printf. A mistyped or stale ARN therefore produces no log line at all — the only symptoms are 403s at a door nobody is watching and counts that never move. Since the ingest door is unauthenticated by design and the ARN allowlist is its first real gate, that is the single most likely misconfiguration in the whole path, and it is the one that leaves no trace.
A log line here does not weaken the gate: the topic ARN is not a secret, and the refusal already tells the caller.
3. DELIVERY events are ingested and then dropped
The event destination subscribes SEND, BOUNCE, COMPLAINT, REJECT, DELIVERY, but mailCountColumn counts only Send/Bounce/Complaint/Reject. Every DELIVERY notification is therefore signature-verified, parsed, and discarded — roughly doubling ingest volume for nothing.
Either stop subscribing it, or count it. Counting is arguably the better end state (a delivery rate is the number an operator actually wants when judging whether a bounce rate is alarming), but dropping it is the one-line change. Note this touches a production write path, so it wants the usual care rather than a drive-by.