chatmail
Gmail account stays "updating..." forever
"[Gmail]/Papelera" is the Spanish name for the Gmail trash folder, since some days I changed the preferred language of my google account to english, maybe that is the problem? core is remembering the old trash folder name and google changed to the english variant, and core is not trying to re-detect the trash folder
- Operating System (Linux/Mac/Windows/iOS/Android): android
- Delta Chat Version: core 1.54.1 (but was happening already in older versions)
- Logs:
2025-01-16 21:25:20.659 28204-28229 DeltaChat E [accId=6] Cannot move messages 55468:55472,55474:55517,55519,55521:55530,55535:55552 to [Gmail]/Papelera, no fallback to COPY/DELETE because delete_to_trash is set. Error: no response: code: Some(TryCreate), info: Some("No folder [Gmail]/Papelera (Failure)")
2025-01-16 21:25:20.659 28204-28229 DeltaChat E Cannot move messages 55468:55472,55474:55517,55519,55521:55530,55535:55552 to [Gmail]/Papelera, no fallback to COPY/DELETE because delete_to_trash is set. Error: no response: code: Some(TryCreate), info: Some("No folder [Gmail]/Papelera (Failure)")
2025-01-16 21:25:20.659 28204-28229 DeltaChat W [accId=6] src/scheduler.rs:418: Failed fetch_idle: fetch_move_delete: move_delete_messages: cannot move batch of messages "55468:55472,55474:55517,55519,55521:55530,55535:55552" to folder "[Gmail]/Papelera": no response: code: Some(TryCreate), info: Some("No folder [Gmail]/Papelera (Failure)")
2025-01-16 21:25:20.660 28204-28229 DeltaChat W [accId=6] src/imap.rs:308: IMAP got rate limited, waiting for 0h 0m 57s until can connect.
2025-01-16 21:25:20.707 28204-28229 DeltaChat E [accId=6] Cannot move messages 6541:6547 to [Gmail]/Papelera, no fallback to COPY/DELETE because delete_to_trash is set. Error: no response: code: Some(TryCreate), info: Some("No folder [Gmail]/Papelera (Failure)")
2025-01-16 21:25:20.708 28204-28229 DeltaChat E Cannot move messages 6541:6547 to [Gmail]/Papelera, no fallback
I think it would be mandatory to redetect all IMAP "system" folders every time the app has been launched.
@adbenitez is the issue reproducible by changing the language?
if so, to close the issue, the deadlock caused by missing folder should be fixed.
there may also be other reasons that a folder is renamed or not exist any longer, so that is anyways worth looking into.
apart from that, wondering if after https://github.com/chatmail/core/pull/7200 it is still needed to detect the trash folder. imu only INBOX is scanned, and maybe the logic can be reverted and trash detection is not needed at all.
i am sceptical in putting much additional effort/traffic/performance in detection of folder meanings of poor server not supporting XLIST. this always has been best effort only, and supporting classic bigtech is not the current focus. if the deadlock is fixed, things are probably good enough, shared usage is not a focus and by deduplication things are probably fine
apart from that, wondering if after #7200 it is still needed to detect the trash folder. imu only INBOX is scanned, and maybe the logic can be reverted and trash detection is not needed at all.
Trash folder detection is still needed, it's not scanned, but it's needed for Gmail case so that messages moved there are actually deleted instead of archiving. I don't know other providers for which Trash detection is needed, still i think we shouldn't unsupport it yet.
The bug here is that scan_folders() isn't called if fetch_move_delete() fails, see scheduler::fetch_idle(). scan_folders() is the one who updates Config::ConfiguredTrashFolder.
...
It seems that this doesn't have other consequences, so the problem is Gmail-specific.