mirror of
https://github.com/bulwarkmail/native.git
synced 2026-10-31 16:06:32 +00:00
Linus Rath
fe0facfea5
Stalwart 1.0 counts every EmailSubmission record of an account against `maxSubmissions` (500 by default), whatever its status or age, and its own purge of old records never runs. The app never removed a record, so after about 500 sends from an account every send, quick reply, read receipt and "Send now" failed with Stalwart's raw "There are too many email submissions, please delete some" error. This ports the webmail fix (48382170). The app now removes the records that can no longer be cancelled. Destroying a record never stops its delivery, but a pending one could no longer be cancelled, so a record EmailSubmission/get reports as pending is never touched: - an immediate send (no undo delay, no schedule) and a read receipt destroy their own record right after the send, riding along with the old-draft cleanup when there is one; only where `urn:stalwart:jmap` is advertised, and never decided by the created undoStatus, which 0.16.10-0.16.16 report as final for held sends - a throttled background prune (`src/api/submissions.ts`) destroys canceled records and final records whose sendAt has passed, going by EmailSubmission/get, in every submission account; it runs at app start, on return to the foreground and after sends and undo - a confirmed cancel (undo, cancel, reschedule, "Send now") destroys the canceled record in a request of its own - an `overQuota` on a submission create prunes at once, on Stalwart walks `EmailSubmission/changes` from "n" for records older than the query's three-day window, retries once, and otherwise throws `SubmissionQuotaError`, shown as a translated explanation in the composer, quick reply, read receipts, the undo bar and the scheduled list; the copy the failed attempt made is removed as before 0.16 never enforces the limit, and destroy never cancels on any version, so the same cleanup runs there unchanged. The undo bar now also says when an undo or "Send now" failed instead of only logging it. The scheduled list reads every page of EmailSubmission/query with calculateTotal; it asked for 200 records, oldest first, so the mail scheduled furthest ahead dropped off once the three-day window held more than that. `SubmissionQuotaError` is added to `jmap-result.ts` as a subclass of `JMAPMethodError`.