fix!: keep primary transport device-local - #8510
Open
hpk42 wants to merge 1 commit into
Open
Conversation
Collaborator
It is ready, waiting for a review. Few comments that are not marked as resolved there are in a discussion state or something for the future. |
hpk42
force-pushed
the
hpk/fix-transport-various
branch
from
August 1, 2026 07:58
3238361 to
ab35e93
Compare
hpk42
force-pushed
the
hpk/local_primary
branch
from
August 1, 2026 13:25
51f2a46 to
4fa5404
Compare
hpk42
force-pushed
the
hpk/fix-transport-various
branch
3 times, most recently
from
August 1, 2026 13:27
eba0573 to
a5f60bd
Compare
Devices no longer implicitely use the From address of sync messages to determine their primary transport. Receivers have no concept of it and own devices may disagree on which relay is reachable because of VPN or different networks: 1. Make setting a primary transport (`configured_addr`) a per-device non-synced operation. 2. Transport rows (add/remove/unpublish) keep syncing like before. 3. A device reelects a primary if a sync message unpublished/removed the current primary if there is a better candidate. 4. `TransportsModified` event is emitted at most once on an incoming transport sync message. Users will notice the change in that changing primary transport in settings/advanced/relays will not synchronize to other devices anymore.
hpk42
force-pushed
the
hpk/local_primary
branch
from
August 1, 2026 13:27
4fa5404 to
8f47f8a
Compare
Contributor
Author
thanks for the note, this PR here is independently ready for review as well. I didn't mean to imply that #8345 replaces it, but rather that they play to the same goal of automated send failover. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[branched is based on #8499 for now]
configured_addrnow just carries a local device's current primary relay choice. If another device removes the underlying transport, or unpublishes is, the device selects the next best from available transports. Devices no longer implicitly use theFromaddress of sync messages to determine their primary transport.Note that this PR, just as main, does nothing to prevent SMTP queued outgoing messages from failing/vanishing when the primary changes. But the PR may well cause less trouble as on main any
Fromchange of a sync message corrupts pending messages. In any case, the eventual real fix is in finalizing and merging #8345 and letting send-failover freely choose a "next primary" for sending if the current primary fails, without any multi-device synchronization repercussions.Users may notice the change in that changing a relay as "used for sending" in settings/advanced/relays will not synchronize to other devices anymore. On the positive side, devices may anyway have different connectivity (VPN, different networks etc.) and letting them make per-device primary relay choices (used for sending and iOS background-fetch) is better compared to them constantly disagreeing over what is a working primary "global" transport.