mirror of
https://github.com/spartanz51/tutabridge.git
synced 2026-06-24 10:54:32 +02:00
Anthony
ffc1d7c9d0
A Mail CREATE event carries the encrypted Mail in `event.instance` and its MailDetailsBlob in `event.blob_instance`. The bridge now pre-decrypts both at the start of each batch into a `pending: HashMap<eid, PendingMail>` pool, then the matching `MailSetEntry CREATE` consumes the entry by element id — no `load_mail` REST call, and when the blob was present the RFC 2822 `.eml` is rendered + written + `has_details = 1` on the spot, so the prefetch loop never has to fetch the body either. Total: a brand-new mail arriving over the event bus now needs 0 REST calls when the server bundles the inline payloads (the common case). Old path required 2 (load_mail + load_mail_details_blob). New MailBackend method `decrypt_inline_mail_details_blob` delegates to the SDK's `CryptoEntityClient::decrypt_inline_and_parse::<MailDetailsBlob>` and extracts the `details` aggregate so the caller stays in terms of `MailDetails`. The bucketer now routes Mail CREATEs to their own `mail_creates` bucket so the pre-decrypt step runs ahead of the MailSetEntry CREATE consumers. Existing CREATE-on-Mail behaviour (nothing happens directly, MailSetEntry CREATE drives placement) is preserved. Fallback chain unchanged: a missing payload, an unresolvable session key, or a decrypt error leaves the pool entry absent and the MailSetEntry handler falls back to its existing inline-MailSetEntry → `load_mail` ladder. 166 bridge lib tests pass (1 new bucket test covers the routing).