DeltaChat Desktop no longer syncs on one of my devices

[ell1e]

DeltaChat Desktop no longer syncs on one of my devices. The UI sometimes will say "Updating..." for a while, but the messages shown in the main contact list never update and they're stuck roughly 10 days in the past, and no new messages are showing. Any individual chat won't load, it just say "Select a chat or create a new chat" and nothing ever happens.

Here's how the main contact list looks like while stuck:

Here's what happens if I try to open up a specific contact's chat, this screen never changes or goes away:

There's at no point any error message shown in the UI.

• Operating System (Linux/Mac/Windows/iOS/Android): Linux
• Delta Chat Version: 1.54.2 (git: flathub), core: v1.156.2
• Expected behavior: device either syncs or shows an error why it doesn't sync
• Actual behavior: device stuck not syncing
• Steps to reproduce the problem: 1. Open DeltaChat desktop
• Screenshots: see above
• Logs:

2025-03-24-13-26-28.log.txt

[nicodh]

Is this a new behaviour that "suddenly" came up?
Or didn't you use that device since 10 days and just realize now that it doesn't sync anymore?

Any changes since last successful sync? Updates etc.?

[nicodh]

Can you create new accounts?

[WofWca]

The fact that an hourglass is displayed instead of the account avatar signifies that BackendRemote.rpc.getAccountInfo(accountId) fails (or just never gets called due to debounce?).

deltachat-desktop/packages/frontend/src/components/AccountListSidebar/AccountItem.tsx

Line 263 in a2576ed

<div className={styles.content}>⏳</div>

deltachat-desktop/packages/frontend/src/components/AccountListSidebar/AccountItem.tsx

Lines 50 to 59 in a2576ed

	const [account, setAccount] = useState<T.Account | null>(null)
	const { openDialog } = useDialog()
	useEffect(() => {
	const updateAccount = debounce(() => {
	BackendRemote.rpc
	.getAccountInfo(accountId)
	.then(setAccount)
	.catch(log.error)
	}, 200)

[ell1e]

Is this a new behaviour that "suddenly" came up?
Or didn't you use that device since 10 days and just realize now that it doesn't sync anymore?

I honestly can't remember if I really didn't use it for that long. Perhaps I didn't, I don't know. But this device worked before, it's not a newly added device or anything.

Can you create new accounts?

Actually, it seems like the second account shown in the screenshot, a nine.testrun.org account, works fine. Only my main account seems to be affected all of a sudden.

[ell1e]

I now tried deltachat-desktop 1.56.0 core 1.157.3, and the affected device remains stuck with the main account. The other 3 devices accessing the same account continue to sync and work correctly with the same main account.

[WofWca]

Looking at the logs, this looks like a core issue to me. I suggest to move it there.

A few things I noticed in the logs: "authserv_id_candidates": "invalidAuthservId".

Another thing: we log a lot here

https://github.com/deltachat/deltachat-core-rust/blob/8a9e60afc309a85aac8adbcf8c7dbeda34ac1997/src/imap.rs#L633-L636

but never get to here

https://github.com/deltachat/deltachat-core-rust/blob/8a9e60afc309a85aac8adbcf8c7dbeda34ac1997/src/imap.rs#L756

It would also be nice to see the logs with the latest core, 1.157.3.

[WofWca]

I encountered something similar to this and to #4844 on a dev version, ce57d43.

I clicked "create account", and there was no "back button". After restarting the app, all the accounts had the hourglass icon on them.
And yes, the RPC server actually hadn't been responding to requests. It had been sending events (get_next_event), but await exp.rpc.getDraft(1, 1) just never resolved. However, if you call a backend method wrong (e.g. omit an argument, await exp.rpc.getDraft(1)), it would respond with an error.

The fact that the "back" button is not displayed also seems to be a side effect of this "not responding" thing. This is where we determine whether to show the "back" button:

deltachat-desktop/packages/frontend/src/components/screens/WelcomeScreen/index.tsx

Lines 32 to 43 in 13355b0

	useLayoutEffect(() => {
	// Show back button when user has already created and configured accounts.
	// On a fresh DC start we will not have any yet.
	const checkAccounts = async () => {
	const accounts = await getConfiguredAccounts()
	if (accounts.length > 0) {
	setHasConfiguredAccounts(true)
	}
	}
	checkAccounts()
	}, [])

If the backend doesn't respond, we'll just never show the back button.

Update: this thing got resolved after I started the "normal" (non-dev version) of Delta Chat. It did not reappear.

[ell1e]

As far as I'm concerned, the difference to #4844 is that this ticket here is about the sync not working as a primary issue, without any explanation nor error. That seems to be some sync related backend bug. The other issue seems to be about a UI bug in handling fast clicks on various buttons unrelated to sync.

[WofWca]

So, looking at the RPC requests / responses, it seems like that select_account is the last request after which the server stops sending any non-event responses. select_account itself never gets a response.

[ell1e]

I have to admit I've since nuked the entire delta chat folder and restored from another device's backup (since the add second device is broken for me in all wifis with all devices I ever tried, it seems to have its own ongoing issues sadly). Simply because I need this device a lot. I understand if that makes additional investigation hard and if it might be better to close this issue for now.

[WofWca]

it might be better to close this issue for now

IDK, I seem to be getting somewhere.

[WofWca]

I'm testing this on core 1.158 now. I have checked that select_account does save the new account id to the accounts.toml file, which happens here:

https://github.com/deltachat/deltachat-core-rust/blob/a8f8d34c25f53301123e7b67c8688df6cda2e4a1/src/accounts.rs#L501-L527

[ell1e]

This was on the PinePhone which uses an SD card. Sometimes the SD card causes bit flips, it seems to be normal for all of them, they're really a horrible kind of storage. To circumvent this, I use BTRFS which at first glance might sound insane on this type of storage - but what it does is checksum all changes, and if something was messed up by the hw, it refuses file access with an I/O error rather than quietly feed you a corrupted file like EXT4 would. Perhaps it might be the case that this happened here, and the error wasn't propagated correctly to the UI?

[WofWca]

When the question is "is it my program misbehaving or it's the file system's fault", the answer is usually the former 😆

[ell1e]

I think useful error handling of such a situation would still be preferable!

[WofWca]

OK, I think this is after all different from #4844. chatmail/core#6726 is about fixing a deadlock of all accounts, but in this issue one account is working.