Frontend: create fetchWithVehicleFallback and use it for the setup wizard

[Williangalvani]

needs testing in non-dev server with no topside internet

Summary by Sourcery

Introduce a fetch helper that falls back to using the vehicle’s caching proxy when direct requests fail and adopt it in the setup wizard for fetching remote configuration resources.

New Features:

• Add a fetchWithVehicleFallback utility that retries failed external requests via the vehicle’s caching reverse proxy.

Enhancements:

• Update setup wizard components to use the new fetchWithVehicleFallback helper when loading scripts and parameter sets from remote repositories.

[Williangalvani]

this should be testable by connecting to the hotspot and trying to setup through there

[Williangalvani]

rebased and tested through hotspot

[github-actions]

Automated PR Review

0. Summary

• Verdict: MINOR SUGGESTIONS ✏️

Adds a fetchWithVehicleFallback helper in core/frontend/src/utils/helper_functions.ts that first tries a direct browser fetch, and on failure retries through the vehicle's nginx /cache/<host>/<path> reverse-proxy so BlueOS can still reach external resources when only the vehicle has internet. Three setup-wizard call sites (DefaultParamLoader.vue, ScriptLoader.vue, Wizard.vue) are switched from raw fetch to the new helper.

1. Correctness & Implementation Bugs

• 1.1 [minor] core/frontend/src/utils/helper_functions.ts:93 — the fallback triggers on any non-response.ok (i.e. any 4xx/5xx too), not just on network/abort failures. A legitimate 404 from docs.bluerobotics.com will now cause a second /cache/… fetch (each with its own 5 s timeout, so up to ~10 s total worst-case) that will almost certainly also 404, doubling the failure latency. Consider retrying only when the direct call throws (network/abort), and returning the direct response otherwise; or at least document this "retry-on-any-non-2xx" behaviour in the JSDoc since callers currently have no way to distinguish "vehicle proxy also failed" from "resource genuinely absent."
• 1.2 [minor] core/frontend/src/utils/helper_functions.ts:103 — url.replace(/^https?:\/\//, '') strips both http:// and https://, but the nginx location hard-codes proxy_pass https://$target; (see core/tools/nginx/nginx.conf:73). A caller passing an http:// URL silently gets upgraded to HTTPS via the proxy, which may or may not exist. All current callers use HTTPS, so no live bug — but either restrict the regex to ^https:\/\/ and throw on http://, or note this in the JSDoc.
• 1.3 [nit] core/frontend/src/utils/helper_functions.ts:99 — the proxied response is returned unconditionally even when it also has !response.ok. That's a reasonable last-ditch behaviour, but the current callers (fetchParamSets, fetchScripts, fetchScript) call .json() / .text() on the returned value with no response.ok check, so a fallback that returns an nginx 502/504 body will be parsed as JSON and surface as a SyntaxError rather than a useful error. Not new to this PR, but worth an if (!response.ok) throw new Error(...) guard in the callers now that failure paths are more common.

6. Code Quality & Style

• 6.1 [nit] core/frontend/src/utils/helper_functions.ts:99 — the catch {} swallows the error silently. A console.debug (or at least binding the error and dropping it into the comment context) would help debugging when the fallback is exercised in the field, especially given the PR body notes "needs testing in non-dev server with no topside internet."
• 6.2 [nit] core/frontend/src/utils/helper_functions.ts:93 — timeout_ms is exposed as a per-call parameter but never overridden by any call site. If there's no near-term plan to vary it, promoting it to a module-level constant (e.g. const FETCH_FALLBACK_TIMEOUT_MS = 5000) removes an unused knob from the public signature.

8. Documentation

• 8.1 [nit] core/frontend/src/utils/helper_functions.ts:87 — the JSDoc is otherwise good, but doesn't mention (a) that non-2xx responses also trigger the fallback (see 1.1), (b) that http:// URLs get silently upgraded (see 1.2), or (c) that the returned Response can still be !ok even after the fallback. A short "Returns" paragraph covering those cases would prevent future call-site surprises.

Generated by PR Review Bot. This is advisory, a human reviewer must still approve.