feat: perform background fetch from all transports - #8592
Conversation
71a5e90 to
50704f9
Compare
With I/O stopped, `background_fetch()` connected only to the transport of `configured_addr` and we now instead fan out to all transports in a controlled loop. Also drop the quota check from this background fetch path: its result is in-memory only, discarded when the iOS notification service exits, and the regular scheduler fetching refreshes it every 60s anyway. Moreover, quota errors/running full is pretty rare since relays generally automatically stay under quota these days. It's another round trip for each transport of each profile and simply not neccessary. Also adds previosly missing online tests and adds `transport_id` to `ImapInboxIdle` Event
50704f9 to
7720b34
Compare
So every background fetch call will always go the full timeout if one of your relays on one of your profiles is offline? In that case android also needs to be updated as I think they also synchronously wait on this function (albeit only for 10 seconds) |
Offline relays will typically immediately fail, so there is no waiting for that. But if you implement concurrent event processing during background fetch, you shouldn't have to worry. The first working relay delivering a message will give you an incoming message, no matter what other connections hang or still need time. |
2 participants
With I/O stopped,
background_fetch()connected only to the transport ofconfigured_addr(see #8572) and we now instead fan out to all transports once in a controlled loop without any notion of primary. This createsNIMAP connections withN=num(all_transports_of_all_profiles), instead ofN=num(all_profiles). Whichever connection for each profile wins, will fetch and lock out the other connections, so that RAM usages through fetching actual IMAP messages should not change.The overall behaviour should actually improve, as we now use the first transport that connects fastest on any given iOS background wake-up. However, the iOS notification extension today would still wait for all profiles and transports to finish their fetch round before showing a message notification to users capped at its 15s
fetchTimeout. This can not be fixed in core, but maybe iOS can drain events concurrently during background fetch, and cancel thebest_attemptsafe-guard if a real notification arrives? This would kind of guarantee iOS sees the first message from whichever transport and whichever profile it arrives, and does not have to wait to the end of all fetches (which might timeout etc.).The PR also drops the
Nquota checks from background fetch: the check result is in-memory only, discarded when the iOS NSE exits, and the regular scheduler fetching refreshes quota every 60s anyway. Moreover, quota full are pretty rare since relays generally automatically stay under quota these days. This savesNconcurrent round trips during background fetch and is simply not necessary.Also adds previously missing online tests.