Skip to content

make primary transport (configured_addr) a per-device choice - #8509

Closed
hpk42 wants to merge 5 commits into
hpk/fix-transport-variousfrom
hpk/local_primary
Closed

make primary transport (configured_addr) a per-device choice#8509
hpk42 wants to merge 5 commits into
hpk/fix-transport-variousfrom
hpk/local_primary

Conversation

@hpk42

@hpk42 hpk42 commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

configured_addr now 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 the From address 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 From change 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 transport.

hpk42 added 5 commits July 31, 2026 18:00
Without the fix, too fast transport changes are ignored at the receiver side.
…essage

Uncaching only after send_sync_transports() could send the sync message
from the old primary address, so other devices never switched.
…ellation

Came across this while investigating more test_transport_synchronization flakiness,
sometimes missing TransportsModified events or getting a missing configured_addr.
The underlying problem was that stopping IO was triggered immediately during
receiving sync messages, potentially *canceling* the processing of the sync message,
effectively de-syncing the device's view on transports.
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 hpk42 closed this Jul 31, 2026
@hpk42
hpk42 deleted the hpk/local_primary branch July 31, 2026 21:34
@hpk42
hpk42 restored the hpk/local_primary branch July 31, 2026 21:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant