cesnimda/jobtrackingapp
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(email): record delivery adapter evidence
CI and Deploy / test (pull_request) Failing after 1m32s
Details
CI and Deploy / deploy (pull_request) Has been skipped
Details

Browse Source
This commit is contained in:
cesnimda
2026-08-09 23:48:59 +02:00
parent e9937accd8
commit d44c8ceb08
7 changed files with 40 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/work-programmes/decisions.md
+10
View File
@@ -409,3 +409,13 @@
- **Consequences:** API integration can reserve a unique attempt before external I/O and fail closed on pending/uncertain records. A provider success followed by database failure remains reconcilable rather than blindly retried. User export must include the non-sensitive metadata; job/account deletion cascades it. The migration is additive and EF-owned with explicit SQLite/MariaDB types.
- **User approval required:** No; the approved MAIL-001 programme requires idempotent/uncertain send safety. This increment is inert and used no provider.
- **Reversible:** Yes. Before reverting `653f011`, stop send admission, reconcile/drain attempts and downgrade `20260809195014_AddEmailSendAttempts`. No production migration has been applied.
## DEC-042 — Send permission is explicit; transport uncertainty fails closed
- **Date:** 2026-08-09
- **Decision:** Request Gmail send and Graph Mail.Send scopes on new/reconnected accounts, derive `CanSend` from the stored granted scope, keep IMAP read-only, and expose one neutral delivery contract. Treat an HTTP rejection as known failed-before-delivery, but any network interruption/cancellation as uncertain.
- **Reason/evidence:** read access cannot authorize send, and existing tokens must not be assumed upgraded. Provider HTTP acceptance is outside the database transaction; after a broken transport the application cannot safely prove that no message was accepted. Mocked HTTP tests prove scope, payload and classification without contacting providers.
- **Alternatives considered:** reuse application SMTP; silently expand existing token authority; mark all errors failed/retryable; expose provider error bodies; add SMTP credentials to the IMAP connection; enable a route before adapter tests. These misrepresent identity, risk duplicate delivery/data exposure, widen secret storage or invert the required dependency order.
- **Consequences:** existing connections show read-only until explicit reconnect consent. Gmail supports its provider thread ID; Graph currently sends a new message and does not claim reply-thread semantics. The later API must reserve the ledger before calling either adapter and surface uncertain state for manual reconciliation.
- **User approval required:** No; this repository-side programme requirement used fake transports only. Real account consent/send still requires an explicitly authorized synthetic provider account.
- **Reversible:** Yes. Revert `e9937ac` to stop requesting/using send permission. Already granted provider permission is managed by the provider/user connection and is not automatically revoked by a code rollback.