Three loose ends from the 2026-07-25 delivery of @hasna/emails 1.3.0 (merged #55, #54, #56, #57, #58, #59; deployed as emails-prod:28). None of them blocks the release; all three were found while verifying it.
1. Phase B — drop the unscoped AWS_* credential pair from emails-prod
emails-prod:28 injects both name pairs from Secrets Manager:
AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY — repoints the container's whole SDK default credential chain at 638389534677EMAILS_SES_ACCESS_KEY_ID / EMAILS_SES_SECRET_ACCESS_KEY — the scoped names 1.3.0's sender reads
The unscoped pair existed to make the 1.2.7 image send without a code change. 1.3.0 is now live and its boot log confirms credentials=environment, so the unscoped pair is redundant and should go — leaving the default chain back on the API task role.
It is safe today only because emails-prod runs ["src/server/index.ts"] and makes no S3/SQS calls. That is a property of the current entrypoint, not a guarantee, so it should not be relied on indefinitely.
Change is in hasna/hasna-xyz-infra, apps/emails/prod/taskdefs/emails-prod.json. Keep it off emails-prod-ingest-worker either way — the alumia principal has no SQS or inbound-bucket access.
2. One send intent is legitimately still uncertain and needs SES-log-level evidence
16bb4fa4-0458-4ceb-ab23-f7373ac14b98 — 2026-07-24T18:40:54Z, andrei@hasna.com, subject "CAPS PROBE 1x 64KiB (sub limita)".
Thirteen of the fourteen uncertain rows were reconciled on evidence. This one cannot be, and it is worth understanding rather than closing:
- AWS/SES CloudWatch on
789877399345, 1-minute buckets, shows Send=1 in the 18:40Z minute — the exact minute this intent was created — and that datapoint is not claimed by any ledger row. The three rows that do carry provider ids (1a08b670, 8e12aae6, 4422f660) are all in the 18:41Z bucket, which shows Send=3.
- The recipient is a verified identity in that sandbox account, so unlike the kpmg.com rows there is no structural reason it would have been refused.
So this row may well be a message that left and whose provider id the old code discarded — the exact defect fixed in #55 (markSendUncertain now persists the provider id). Closing it as not_sent would file a delivered message as failed. It needs the SES event/delivery log for that minute, not a metric.
3. The prod client-env vault item carries a session token the server rejects
hasna/xyz/opensource/emails/prod/client-env contains an EMAILS_SESSION_TOKEN (emss_…, expired) and a working EMAILS_SELF_HOSTED_API_KEY. resolveSelfHostedConfig prefers the session token, and prod answers {"error":"session is invalid or expired"}, so the standard operator config is 401 against production out of the box. Every CLI call in this delivery needed an explicit EMAILS_SESSION_TOKEN= override.
Fix either side: drop/refresh the token in the vault item, or make the resolver fall back to the API key when a session token is present but rejected. The second is better — an expired token should not shadow a valid credential.
Three loose ends from the 2026-07-25 delivery of
@hasna/emails1.3.0 (merged #55, #54, #56, #57, #58, #59; deployed asemails-prod:28). None of them blocks the release; all three were found while verifying it.1. Phase B — drop the unscoped
AWS_*credential pair fromemails-prodemails-prod:28injects both name pairs from Secrets Manager:AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY— repoints the container's whole SDK default credential chain at638389534677EMAILS_SES_ACCESS_KEY_ID/EMAILS_SES_SECRET_ACCESS_KEY— the scoped names 1.3.0's sender readsThe unscoped pair existed to make the 1.2.7 image send without a code change. 1.3.0 is now live and its boot log confirms
credentials=environment, so the unscoped pair is redundant and should go — leaving the default chain back on the API task role.It is safe today only because
emails-prodruns["src/server/index.ts"]and makes no S3/SQS calls. That is a property of the current entrypoint, not a guarantee, so it should not be relied on indefinitely.Change is in
hasna/hasna-xyz-infra,apps/emails/prod/taskdefs/emails-prod.json. Keep it offemails-prod-ingest-workereither way — the alumia principal has no SQS or inbound-bucket access.2. One send intent is legitimately still
uncertainand needs SES-log-level evidence16bb4fa4-0458-4ceb-ab23-f7373ac14b98— 2026-07-24T18:40:54Z,andrei@hasna.com, subject "CAPS PROBE 1x 64KiB (sub limita)".Thirteen of the fourteen uncertain rows were reconciled on evidence. This one cannot be, and it is worth understanding rather than closing:
789877399345, 1-minute buckets, showsSend=1in the 18:40Z minute — the exact minute this intent was created — and that datapoint is not claimed by any ledger row. The three rows that do carry provider ids (1a08b670,8e12aae6,4422f660) are all in the 18:41Z bucket, which showsSend=3.So this row may well be a message that left and whose provider id the old code discarded — the exact defect fixed in #55 (
markSendUncertainnow persists the provider id). Closing it asnot_sentwould file a delivered message as failed. It needs the SES event/delivery log for that minute, not a metric.3. The prod client-env vault item carries a session token the server rejects
hasna/xyz/opensource/emails/prod/client-envcontains anEMAILS_SESSION_TOKEN(emss_…, expired) and a workingEMAILS_SELF_HOSTED_API_KEY.resolveSelfHostedConfigprefers the session token, and prod answers{"error":"session is invalid or expired"}, so the standard operator config is 401 against production out of the box. Every CLI call in this delivery needed an explicitEMAILS_SESSION_TOKEN=override.Fix either side: drop/refresh the token in the vault item, or make the resolver fall back to the API key when a session token is present but rejected. The second is better — an expired token should not shadow a valid credential.