l

Maybe instead of `status == flate2::Status::BufError` the test should check that input has not advanced? So if input has not advanced and output has not advanced, then break out of...

First thing I want to know is if this is still sent as a sticker viewtype or gets converted to image by heuristics. For some history regarding sticker heuristics: -...

Similar project: https://github.com/joaoh82/rust_sqlite

Do not forget to "hide whitespace changes" when reviewing: 

`test_download_limit_chat_assignment` is broken because we cannot assign undownloaded messages to chats without the `To` header probably.

We also had similar problem reported by @dignifiedquire on 2025-01-07: ``` Delta Chat Desktop 1.50.1 (git: v1.33.0-1248-gc04da97a) Delta Chat Core v1.152.1 ```

In my log for non-chatmail account that got into 100% CPU state I have this: ``` 2025-01-25T08:22:57.958Z core/event INFO "" 1 "src/imap/idle.rs:87: INBOX: Idle wait was interrupted" 2025-01-25T08:22:57.959Z core/event INFO...

I improved logging around IMAP in https://github.com/deltachat/deltachat-core-rust/pull/6485, this got into 1.155.2 IDLE code inside `async-imap` looks suspicious, it is not straightforward, I also don't like that it has `unwrap`, `assert`...

Got this problem on Desktop again. Core v1.155.1 without improved logging unfortunately, so did not look into the logs. Inspecting connections with `ss`, there is an ESTAB state for connection...

This code also does not look right: https://github.com/deltachat/deltachat-core-rust/blob/0973a462450e44094ff3d0fc991cb29364bc9204/src/imap/idle.rs#L75-L82 `idle_wait` is a future returned by [`wait_with_timeout`](https://docs.rs/async-imap/0.10.2/async_imap/extensions/idle/struct.Handle.html#method.wait_with_timeout) and I don't think it is cancellation-safe. If we receive interrupt, dropping `interrupt` cancellation token...