Skip to content

Conversation

@iequidoo
Copy link
Collaborator

This reproduces the bug when a new transport doesn't become primary on the 2nd device because I/O isn't restarted when a new transport is added from a sync message, so INBOX from the new transport isn't fetched.

This reproduces the bug when a new transport doesn't become primary on the 2nd device because I/O
isn't restarted when a new transport is added from a sync message, so INBOX from the new transport
isn't fetched.
.await?;

context.emit_event(EventType::TransportsModified);
// context.scheduler.restart(context).await;
Copy link
Collaborator Author

@iequidoo iequidoo Dec 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't fix the bug quickly because this doesn't compile with error: future cannot be sent between threads safely [...].

Another problem is that we should fetch all existing messages from the new transport, but Config::FetchedExistingMsgs is already 1 at this moment. Otherwise the fix won't be reliable.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FetchedExistingMsgs does not actually fetch messages. fetch_existing_msgs just looks for existing email addresses in unencrypted headers and adds them to contacts.

@iequidoo iequidoo added the bug Something is not working label Dec 22, 2025
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

Successfully merging this pull request may close these issues.

3 participants