Linked environment shows "Not answering right now." after one failed check #34195

What happened

Settings > Connections showed my linked machine as "Full access · Not answering right now." The machine was up and its relay address answered: 219 of 220 requests to /.well-known/t3/environment returned 200 over 3.5 minutes.

Diagnosis

statusOf in apps/server/src/peer/PeerLinks.ts makes one GET to <url>/.well-known/t3/environment per stored address, with a 10-second timeout (3 on loopback) and no retry. When none answers, the link lists as unreachable. The Connections page lists only when it is opened, so one missed check stays on screen.

My network dropped for 0.1 to 0.4 seconds many times an hour, with DNS stalling for seconds around each drop (a WSL mirrored-networking problem, microsoft/WSL#42232). A check that lands on a drop fails, and the link looks dead when it is not. statusOf is the same on main at c82e1ba.

Suggestions:

• Retry once or twice with a short delay before calling a link unreachable.
• Check again on a timer while the Connections page is open, or offer a "Check again" button on the row.
• Show when the link last answered, such as "Last answered 2 minutes ago", so one miss reads as a blip.
• Show the error when there is one. Here the stored error was empty and the row fell back to the generic text.

Steps to reproduce

Not deterministic: the check has to land on a network drop.

1. Link a second machine through the relay.
2. On the machine that holds the link, have the network drop for a fraction of a second, repeatedly. Here WSL 2 with mirrored networking removed and re-added its default route about twice a minute.
3. Open Settings > Connections while that happens.
4. Sometimes the row reads "Not answering right now.", although the machine answers requests made just before and after.

Version

0.1.9-nightly.20261110.4478

Environment

Server on Ubuntu 24.04 under WSL 2 (WSL 3.0.3.0, mirrored networking, Windows 11 build 26200), web client, linked through the relay to a second machine on Arch Linux

Evidence

# 220 GETs to the linked machine's relay address, /.well-known/t3/environment, over 3.5 minutes
200: 219    failed: 1
# a 5-minute capture on the machine that holds the link (ip -ts monitor)
IPv4 default route removed and re-added: 11 times, each gap 0.1 to 0.4 s

Related issues

#28531 and its open PR #28543 touch the same probe. Not a duplicate: they are about how long listing takes when a peer sleeps; this is about one missed probe showing a healthy link as down.

Fix applied or workaround

Opening the Connections page again checks again. I also stopped the network drops on my side by fixing the Wi-Fi interface metric on Windows (see the WSL issue).

Filed by

Claude Code (claude-fable-5-2) in a T3 Code thread, not through t3 triage