feat(wifi): make backend selection re-entrant so a transient probe failure recovers without a restart (#609 follow-up)

[vibechoom]

Deferred scope from PR #609 (the #607 probe fix). Filing so it doesn't stay parked only in a merged PR body.

What

#609 made an inconclusive backend probe distinguishable from "this host has no wireless hardware" — the failure now logs at error! and points at systemctl --user restart trollshell. What it deliberately did not do is recover on its own. From the PR body:

Re-probing / retrying until a backend appears. wifi/mod.rs branches on the verdict and spawns a different watcher per backend, so re-probing means restructuring that selection, not re-calling a function. I did not touch the watcher-spawning structure, and deliberately did not add a retry loop inside probe_backend either — a retry would mask how often the failure actually [occurs].

So a transient D-Bus failure at startup — a slow NetworkManager on a cold boot is the obvious candidate — still silences the Wi-Fi section for the whole session, and the only remedy is a manual restart.

Severity

Medium. The user-visible symptom is the one originally reported in #607 (Wi-Fi section simply gone), and the workaround is a shell restart. #609 downgraded it from silent-and-inexplicable to loud-and-explicable, which is a real improvement but not a fix.

Why it wasn't just fixed

Two reasons, both good:

1. It's a restructure, not a retry. wifi/mod.rs branches on the verdict and spawns a different watcher per backend, so "probe again" means making backend selection re-entrant rather than a one-shot at startup.
2. fix(wifi): a failed backend probe is no longer indistinguishable from "no backend" (#607) #609's author deliberately wanted the failure to stay loud so we learn how often it actually fires. A retry loop added at the same time would have hidden exactly the signal the error! line was added to collect.

Recommendation

Gate this on evidence, not on appetite. Point 2 is the important one: the whole reason the error! line exists is to measure frequency, and building the retry now discards that measurement before it's taken. Wait until we have at least one confirmed sighting of the log line in the wild (#607 is the live candidate — see the note there about the line retroactively confirming the diagnosis).

If and when it's worth building: make the backend selection re-entrant — a supervising task that owns "which watcher is running" and can tear one down and spawn another — rather than a retry inside probe_backend. Bounded exponential backoff, and it must stop retrying once a backend is chosen, so a working host doesn't poll forever.

Refs #609, #607.

[vibechoom]

Mara's #607 update (a restart cured it, no recurrence since) lifts the evidence gate I put on this. I've now mapped the code properly before proposing anything, and the map splits this issue cleanly in two — one half is contained and fixes the reported bug, the other is genuinely invasive and shouldn't be bundled with it.

Where the latch actually is

Not in probe_backend. #609 already made that honest — wifi_backend.rs:187-209 returns Result<BackendChoice, ProbeError>, with BackendChoice::None documented as a positive finding distinct from "I couldn't ask".

The collapse is one layer up, at wifi/mod.rs:168-186:

fn select_backend(rt: &tokio::runtime::Handle) -> BackendChoice {
    match rt.block_on(crate::wifi_backend::probe_backend()) {
        Ok(choice) => { …; choice }
        Err(e) => {
            tracing::error!(…, "wifi: backend probe was INCONCLUSIVE …");
            BackendChoice::None   // ← the latch
        }
    }
}

select_backend is called exactly once from Service::start, and its value is consumed by the match at :205. The wifi_backend.rs:34-35 module doc already says re-probing is "deliberately still unsolved; see #607" — so this is an acknowledged gap, not a half-built feature.

Why the obvious fix is wrong

"Just retry inside select_backend" would hang shell startup. That function runs rt.block_on(...) on the calling thread during Service::start, so a retry loop there blocks the GTK main thread until the bus answers — trading a broken Wi-Fi card for a frozen shell. Worse trade.

The split

Phase 1 — retry before committing. Contained, and it is what Mara actually hit.

The key observation: when the probe returns Err, nothing has been spawned yet. There is no watcher to stop, no name owned, no agent exported. So retrying until the probe is conclusive needs zero cancellation machinery — which is the entire difficulty of the other half.

The shape already exists in this repo, in networkd.rs:305-368: Service::start builds the Mutables and spawns one supervised task, and the probe and the match backend {…} both happen inside that task (:316, :321-362). One task owns the whole lifecycle and decides internally. wifi/mod.rs instead decides on the calling thread and then scatters up to three independent spawns per arm — which is exactly why it can't currently re-enter anything.

So phase 1 is: move the probe and the branch inside a single spawn_supervised closure, retry the probe with backoff while it is inconclusive, and commit once it is conclusive. BackendChoice::None (a real answer) still commits immediately — we retry "couldn't ask", never "nobody's there".

One consequence that must be handled, and it's the only non-mechanical part: WifiHandles.backend (mod.rs:136) is a plain field set once in the struct literal at :302, read by get_backend() (:374-381) as a snapshot. If the branch moves inside the task, start() returns before the backend is known — so that field has to become something settable-later (a Mutable<WifiBackend>, with get_backend() reading its current value). Command dispatch (scan, connect_network, …) then sees None until the probe concludes, which is indistinguishable from today's pre-discovery startup window.

Phase 2 — true re-entrant switching. Invasive, and I am filing it separately.

Picking up a daemon that appears later, or moving between iwd and NM at runtime, is a strictly harder problem, because by then you have committed and must stop what you started. Today you cannot:

• spawn_supervised (hytte-reactive/src/supervisor.rs:66-72) spawns and returns () — no handle, by construction. Both watchers use it.
• own_name(…).start() (hytte-bus/src/own.rs:180-193) discards its JoinHandle, and OwnNameSignal has no Drop — dropping it drops your read access, not the task.
• Only ExportHandle (hytte-bus/src/export.rs:31-49) has a real teardown Drop, and its doc says so explicitly. That is the one piece of prior art for what a droppable teardown handle should look like here.

Plus the per-backend path caches are asymmetric: iwd writes process-global OnceLock statics (mod.rs:54,69) with no reset path, while NM threads its own Arc<RwLock<String>> inside the WifiBackend::NetworkManager(…) payload. An iwd→NM→iwd cycle would leave stale iwd path data in a global nothing invalidates.

So phase 2 needs a cancellation primitive designed and added first. That is architecture work, not a fix, and bundling it with Mara's bug would hold a contained fix hostage to it.

The reassuring part

Blast radius is smaller than I feared. Every consumer — panels/network/wifi.rs, wired.rs, panels/vpn.rs, overlays/prompt.rs — subscribes via real signals and already renders the empty state, because that is exactly what is on screen from process start until first discovery completes. An empty→populated transition from a successful re-probe is not a new code path; it is the same transition that already happens once per boot, happening again.

Constraint carried from #607

The retry must not silence the diagnostic. Log every inconclusive attempt and log the recovery. #609's error! line exists to measure how often this fires, and a retry that recovers quietly would trade a visible permanent bug for an invisible intermittent one — worse for the exact situation Mara was in, with no in-UI hint anything had failed. Recovering and staying observable is the requirement.

Open question for @annikahannig — and it ties to #621

Phase 1 needs a retry policy, and #621 asks the same question for networkd's startup refresh. These two should not diverge.

My lean, stated on #621 and unchanged: bounded retry with backoff, then give up loudly at error! — so the give-up is visible in journalctl rather than the shell silently polling a dead bus forever. Retry-forever is the alternative and is defensible; it just needs to be a decision rather than an accident, and it should be the same decision in both places.

I'll re-scope this issue to phase 1 and file phase 2 separately so neither gets lost.