No rooms displayed after update (sign-on apparently succeeded)

[mi5o]

After upgrading to foss-signed-27.10.2022-V1.apk, the application claimed the cache has to be cleared. I consented, but once finished, I saw no rooms. I killed the application, started afresh and again, no rooms. I killed the application again, I did a cache-clear directly from Android settings, but to no avail.

Later, I tried foss-signed-31.10.2022-V1.apk. This time the application happily started, no mention about cache clearing, yet it displayed no rooms, just an empty screen. Remembering the cache might be an issue, I killed the application, I did a cache-clear directly from Android settings, restarted the application, and voilà!, now it works just fine.

I assume users are not supposed to go through manual cache cleaning every time they update the application. So I hope this will be mitigated well before leaving the pre-release or beta status. Or, at least, there should be an advice on an empty screen saying that if the user is convinced that some rooms has to be there, and there are none, then cleaning of cache might help, although unfortunately without guarantee.

[skdubg]

i have the same issue too, you see the rooms again after logout and relogin

[mi5o]

@skdubg: Be aware of doing so. Logout and login of Matrix session with encrypted rooms has additional implications, other than those people might expect. AFAIK, logout (in Matrix protocol) implies irreversible dropping of device ID and associated credentials. New login then generates new device ID and new credentials. But the previous (no longer accessible) device ID sticks. All messages sent from this device ID are still bearing the reference to it. Just as everybody in the room sees all your device IDs, which you have been using throughout the past. And each user needs explicitly declare his/her trust towards each of your device IDs (this is Cartesian product), otherwise Matrix client should complain about possible security hole. This has been recently somewhat simplified, but only from the user point of view, technically the requirement is still there. Unless I misunderstood something.

[ouchadam]

the majority of these errors stem from a lack of database migrations, I've been holding off adding them until the data schemas are in a more final state, which has the side effect of needing to clear the cache when updating (if done from within the app when updating it avoids deleting the crypto data)

there's also a bug where the settings -> clear cache option doesn't always work due to the background sync not being cancelled

[mi5o]

I cannot comment on frequency of different types of causes. But in this last example, in release 06/11/2022-V2, this was not the case. The application clearly missed a SQL table, which simply was not there.

I have no idea how these .sq files do work. I can see in MutedRoom.sq that it starts with CREATE TABLE IF NOT EXISTS command, which will not be sufficient for modified table, but it must be sufficient for newly created table. Yet the code — apparently — has not been executed.

BTW, chances are, #252 is caused by the same.

In enterprise-grade solutions, the database stores its own version. So if any newer version of an application is trying to access the database and it recognizes that the database is obsolete, it can fire all migrating scripts between declared database version and the latest version, before doing its own job. Maybe in Android environment, this is somehow handled by various frameworks. But still, I see no information, from which the application could decide, how old the database is. Of course, this might wait until the database somehow stabilises, I am just spewing unsolicited advice.