Android clients are still broken

[sairuk]

I'm am currently running the 1.32.7 docker image with multiple (5) android users on client versions 2024.10.0 (11270) or 2024.12.0 (19597).

All users lose access to their vaults with the official bitwarden android client, behaviour began while we were on 1.32.5 and earlier android client versions and has persisted through 1.32.6 to 1.32.7 vw.

Reviewing previous PRs, issues etc and attempting the fixes like clearing cache/data/app, rebooting, rolling keys etc has no effect to restoring access however a reinstall will allow initial sync of the vault but eventually (could be days) it will stop working again with "We were unable to process your request. Please try again or contact us"

The only particulars I have in place for my main instance is

• restricted access to our internal network (so when one of my users is out and they happen to have lost access to their vault, they have to wait until they return to reinstall and regain access)
• a custom port
• multiple shared vaults

any debugging tips, thoughts on rectifying this?

[BlackDex]

Use adb logcat to see what the issue is.
It does sometimes help to fully clear all data of the app, and fully login again.

[BlackDex]

Strange, because if the sync fails, it normally shows an exception in de adb logcat output, which might be cryptic, but could help finding the issue. I didn't meant creating a whole new Vaultwarden instance, but a new account without any passwords or organizations, and see if that works, and what happens of you add passwords or invite them to an org etc...

[sairuk]

It is fine I knew what you meant and i will give a new user a go as well. Based on recent findings I think that may work out ok, still a bit of work but not terrible.

I've migrated the single user instance to a new instance and now the latest server (1.32.7) / client (2024.12.0) software (so far) is happy enough with each other while prior to this with their old db the android app at the same version failed (this is on Android 12). Perhaps it is some additional legacy db entry breaking stuff for the new android clients.

Also while going through some devices here I have found one of my users is successfully connecting to my existing 1.32.7 instance with 2024.12.0 (10597) on Android 11 / Pixel 2, they were only added quite recently when we were on 1.32.6 while my Android 14 / Pixel 4a on any client after 2024.10.0 is broken. This was the first user added when we migrated from pass which was a while ago now but what versions of vw we were on at the time escapes me atm.

[BlackDex]

The android error during the sync will be useful to see if we still need to fix something wrong on the db side. Else a har/sync response would be useful to try and figure out what could be wrong.

[sairuk]

I've fixed this now, the sync wasn't failing. So no expected logcat messages. It appears bw was failing to successfully parse the data it received from vw.

The newer bitwarden clients appear to fall over on any invalid match entries, in my case it appears I had uri match entries that were an empty string "" instead of null as evidenced in my exported data. Annoying that it kills the entire vault access without any reasonable error messages. At a guess the problematic entries may have been the result of a previous batch migration from pass a while back but I no longer have access to the old data to confirm.

To repair this I exported the vaults for the affected users, processed them with python to set any match with a uri to null then imported the data into a new instance/user and found that the latest android client was happy with the vault. I then purged the users vaults on the older instance and imported their corrected data and it is happy now.

I also had an org breaking 2024.12.0, due to what I expect was also missing match entries that I manually fixed, however this was not enough to get sync working. Turning off access to collections one by one was enough to troubleshoot the issue as once the offending collection access was disabled the client could sync again. To fix this I ended up exporting and importing the data into a new org, however no changes were made to the exported data prior to import, the android client successfully synced the new org/collections.

That is now server 1.32.7 and client 2024.12.0 working for me.

Thanks for you help looking into this issue, if you have any further questions let me know.

[BlackDex]

Thanks for reporting back, i have fixed this issue via #5332