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

docs(email): record retry rotation evidence
CI and Deploy / test (pull_request) Successful in 4m39s
Details
CI and Deploy / deploy (pull_request) Has been skipped
Details

Browse Source
This commit is contained in:
cesnimda
2026-08-10 10:22:48 +02:00
parent 29de2632f6
commit b0537b8575
6 changed files with 28 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/work-programmes/decisions.md
+10
View File
@@ -579,3 +579,13 @@
- **Consequences:** unsaved edits are intentionally not refresh-durable; saved replies are. A successful send attempts revisioned draft cleanup, while the persisted client ID keeps any surviving copy duplicate-safe. Compose-new-message and durable failed-attempt identity rotation remain separate increments.
- **User approval required:** No; this is approved local MAIL-001 UI work with mocked APIs and no email/provider action.
- **Reversible:** Revert `d3d2b67`; stored drafts remain available through the API/export but no UI consumes them.
## DEC-059 — Rotate draft delivery identity only from a terminal failure
- **Date:** 2026-08-10
- **Decision:** Add an explicit revisioned `new-attempt` action that issues a new draft client-request UUID only when the authenticated owner's matching ledger row is `failed`. Wire the existing Prepare new attempt UI to this action for saved drafts.
- **Reason/evidence:** ordinary edits/refresh must preserve idempotency, while a provider-confirmed failure needs a deliberate recovery path. Pending/sending/uncertain/sent states cannot disprove delivery and must not rotate. Real-SQLite owner/stale/status tests and mocked UI pass.
- **Alternatives considered:** let the browser invent UUIDs; rotate on any error; rotate during save; automatically retry failed sends. These lose durable state, can duplicate uncertain/sent mail or weaken explicit approval.
- **Consequences:** definitively failed drafts can be reviewed and retried under a new ledger identity; all ambiguous or successful attempts remain non-retryable. Unsaved local drafts retain the existing explicit local new-attempt behavior because no durable ledger relationship exists yet.
- **User approval required:** No; this is approved safety work with fake/local evidence and no email/provider call.
- **Reversible:** Revert `29de263`; saved failed drafts then have no durable retry rotation and the UI should not offer that action.