WiFi credentials flow: unbounded polling against a dead origin, no hotspot fallback on failure

[eliasbakken]

Problem

After submitting WiFi credentials on the setup page, the board tears down its Hotspot AP and switches to station mode. If the browser loaded the page from the hotspot's address, its origin becomes permanently unreachable the moment that AP goes down - regardless of whether the station-mode connection ultimately succeeds or fails. Both outcomes look identical to the browser: unreachable.

Two separate gaps compound this:

1. Frontend polling never times out and can never succeed anyway

client/src/components/TheWifiSetup.vue's pollConnectResults() retries every 1s forever - no counter, no elapsed-time cutoff, on every path (still-connecting, and even hard request failures in the catch block):

async pollConnectResults() {
  try {
    const res = await axios.get('/api/wifi_poll_connect');
    ...
    if (res.data.isConnecting == true) {
      setTimeout(this.pollConnectResults, 1000);
    }
    ...
  } catch (err) {
    setTimeout(this.pollConnectResults, 1000);
  }
},

axios.get('/api/wifi_poll_connect') is a relative URL, resolved against the page's origin at load time. Once the hotspot AP is torn down, that origin is gone for good from the browser's perspective - polling it can never observe a result either way, success or failure.

2. No hotspot fallback if the station-mode connection fails

Neither bin/prod/wifi-connect (interactive credentials-page flow) nor bin/prod/wifi-bringup (boot-time) restores the Hotspot AP if connecting to the configured network fails (wrong password, AP out of range, DHCP timeout, etc). The board is left in station mode with no working connection and no hotspot - unreachable until physical intervention. This is a real robustness gap independent of the UI issue above.

Suggested fix

1. Frontend: stop relying on polling the pre-switch origin for the eventual outcome. Bound polling to a short window (~10-15s) only to catch fast, local failures that happen before the AP is torn down (e.g. validation errors). Once the switch is underway, show guidance instead: "The board is switching to your Wi-Fi network. Reconnect this device to the same network, then continue at recore.local" with a button/link that navigates to http://recore.local/, leaning on mDNS to resolve wherever the board actually ends up.
2. Backend: wifi-connect should restore the Hotspot AP if the station-mode connection doesn't succeed (mirroring the fallback wifi-bringup already has for the "eMMC mount failed" case), so a bad password or unreachable AP can't leave the board silently unreachable.

Backend fix (#2) is the more important one - it's an actual failure mode with real consequences, not just UX polish.

Related

While investigating this, bin/prod/wifi-connect's DHCP wait was bumped from 10s to 30s (MAX_RETRIES=10 -> 30) as an unrelated quick fix - not yet committed.