Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bcc_self is reverted to 0 after upgrade of existing multi-device setup #6432

Closed
link2xt opened this issue Jan 13, 2025 · 5 comments
Closed
Labels
bug Something is not working

Comments

@link2xt
Copy link
Collaborator

link2xt commented Jan 13, 2025

Users report that in a setup with Android (1.50.4 from F-Droid) and Desktop (1.48.0 x86_64 .deb release) and chatmail account bcc_self was reverted to 0 on Android, resulting in messages send from Android not appearing on Desktop. The setting is not displayed on Android for chatmail accounts, but as a workaround, exporting a backup on Android and immediately destroying it worked. Upgrading Desktop to 1.50.1 did not result in bcc_self reverting there to 0.

The problem was likely introduced in #6344
This change is part of core 1.153.0. Android 1.50.3 uses core 1.152.0 and Android 1.50.4 uses core 1.153.0. Desktop 1.50.1 still uses core 1.152.1, this is likely why the problem did not appear there yet, it may still revert to bcc_self=0 after upgrade.

@link2xt link2xt added blocker bug Something is not working labels Jan 13, 2025
@link2xt
Copy link
Collaborator Author

link2xt commented Jan 13, 2025

Migration in #6344 inserts bcc_self=1 into config table if config table contains delete_server_after=0. If delete_server_after simply does not exist in the table, then migration does nothing.

Maybe the migration should have been INSERT OR REPLACE, not INSERT OR IGNORE. Maybe the user switched the setting back and forth when it was still not hidden, then migration does nothing.

@link2xt
Copy link
Collaborator Author

link2xt commented Jan 13, 2025

Unless someone finds other reasons for why this could have happened, I suggest we copy the migration, but now with INSERT OR REPLACE instead of INSERT OR IGNORE, and let it run once again.

@link2xt link2xt removed the blocker label Jan 13, 2025
@link2xt
Copy link
Collaborator Author

link2xt commented Jan 13, 2025

We don't have a clear way to reproduce it and it does not seem to happen to any of developers, so maybe it's a rare case. I upgraded all my devices to the latest core and don't have this bug.

Since bcc_self essentially means "multi-device", one way to automatically fix this case would be to enable it when we see outgoing message, or at least every time we download a sync message. Sync message in our inbox is a clear indication that we have a multi-device setup.

@link2xt
Copy link
Collaborator Author

link2xt commented Jan 13, 2025

Replaced with #6433

@link2xt link2xt closed this as not planned Won't fix, can't repro, duplicate, stale Jan 13, 2025
@iequidoo
Copy link
Collaborator

I think this might happen because of the bug in the migration, it should actually be

            "INSERT OR IGNORE INTO config (keyname, value)                                                                                                                                                           
             SELECT 'bcc_self', '1'                                                                                                                                                                                  
             FROM config WHERE keyname='delete_server_after' AND value!='1'

instead of ... AND value='0'. The user might set delete_server_after to some value other than 0 or 1 when that was possible in UIs.

iequidoo added a commit that referenced this issue Jan 14, 2025
…=1 (#6432)

Users report that in a setup with Android (1.50.4 from F-Droid) and Desktop (1.48.0 x86_64 .deb
release) and chatmail account `bcc_self` was reverted to 0 on Android, resulting in messages sent
from Android not appearing on Desktop. This might happen because of the bug in migration #127, it
doesn't handle `delete_server_after` > 1. Existing chatmail configurations having
`delete_server_after` != 1 ("delete at once") should get `bcc_self` enabled, they may be multidevice
configurations:
- Before migration #127, `delete_server_after` was set to 0 upon a backup export, but
  then `bcc_self` is enabled instead (whose default is changed to 0 for chatmail).
- The user might set `delete_server_after` to a value other than 0 or 1 when that was
  possible in UIs.
So let's add another migration fixing this. But still don't check `is_chatmail` for simplicity.
Hocuri added a commit that referenced this issue Jan 14, 2025
Some migrations change the `config` table, but they don't update the
cache. While this wasn't the cause
#6432,
it might have caused a similar bug, so, let's clear the config cache
after every migration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working
Projects
None yet
Development

No branches or pull requests

2 participants