Skip to content

[Bug]: Connections keeps stale network endpoints after reopening settings #15751

Description

@arthurkatcher

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web (desktop Connections settings)

Steps to reproduce

  1. Open desktop Settings → Connections before Tailscale has connected and let the endpoint list load.
  2. Connect Tailscale outside T3, so the host gains a new Tailscale interface/address.
  3. Wait longer than the configured 30-second stale period, leave Connections, and reopen it.
  4. Compare the displayed endpoints with a fresh desktop endpoint-provider read. Reload the renderer to compare with a fresh frontend state.

Expected behavior

Reopening Connections after its endpoint snapshot becomes stale should discover the current addresses without restarting the desktop app.

Actual behavior

The previous endpoint list remains cached and the newly available address does not appear. The desktop provider reads current interfaces when invoked, but the frontend state can prevent that new read.

Impact

Minor bug or occasional failure: network changes during a session leave sharing options stale and require a renderer reload or a separate setting mutation to trigger refresh.

Version or commit

Observed while using 0.0.45. State-layer reproduction confirmed on main at 4ee6bfd50ef4a089440d5c3662db2298da9cc50e.

Environment

Ubuntu 24.04.4 LTS, T3 Code Desktop; Tailscale connected after the Settings list was loaded.

Investigation

desktopNetworkAccess.ts configures Atom.swr({ staleTime: 30_000, revalidateOnMount: true }) followed by Atom.keepAlive. The wrapper stays mounted across consumer remounts. No focus signal or network-change invalidation is configured. Existing explicit refresh calls are tied to settings mutations.

A deterministic isolated probe extracted the production factory and used the repository's installed Effect runtime. The bridge first returned only a LAN endpoint. After changing its response to include Tailscale, advancing Date.now by 60,001 ms, and unmounting/remounting the consumer, the cached snapshot and read count were unchanged. Explicit registry.refresh(atom) loaded the new endpoint immediately.

Initial: LAN only; bridge reads = 1
After simulated 60 seconds and remount: LAN only; reads = 1
After explicit refresh: LAN + Tailscale; reads = 2

This is state-layer evidence; it is not a recording from a rebuilt Electron client. The separate CGNAT misclassification is not needed to reproduce the stale cache.

Workaround

Use View → Reload to recreate the frontend state. A reload refreshes the list but does not repair incorrect address classification in the endpoint provider.

Activity

  1. juliusmarminge commented on Oct 4, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    Thanks for the precise state-layer probe, @arthurkatcher! It pointed right at the cause.

    What I found

    Confirmed on main at 4ee6bfd. This is separate from #15750: the desktop provider reads current interfaces whenever it's called, so this is purely the renderer cache.

    Likely fix area

    Some options:

    • Refresh the endpoint atom when entering the Connections route, like the SSH dialog does.
    • Change the atom composition so a stale remount actually revalidates (for example, keepAlive on the source atom rather than the SWR wrapper).
    • Either way, add a test that advances past 30 s and asserts the bridge is called again.

    Watching interfaces live while the page stays open would be a separate change.

    A maintainer will decide on the fix direction.

  2. added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions