fix(majestic): don't let a missing info.json hide the config

[keyldev]

Fixes #88

Newer lite Majestic builds (gk7205v200, 2.6.09.24-lite) answer 404 on /api/v1/info.json. The desktop camera page loaded config.json and info.json together via Task.WhenAll, so the 404 threw away a perfectly good config and the panel showed "Majestic returned HTTP 404".

• MajesticHttpClient.GetInfoAsync: 404 now means "no info", same as the existing HTML-fallback case
• SingleCameraPageViewModel: an info.json failure (including a timeout) no longer fails the config load
• The web API and CameraConnectService already treated info as optional

Builds clean; not verified on a real camera.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Keep Majestic config editable when info.json is unavailable

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Treat missing Majestic info.json as unavailable metadata rather than a failed request.
• Keep the desktop config editor available when optional camera information fails or times out.

Diagram

graph TD
  config["config.json"] -->|"required config"| client["Majestic HTTP client"] -->|"config and info"| desktop["Desktop view model"] --> panel["Editable panel"]
  info["info.json"] -->|"404 means empty info"| client

Loading

High-Level Assessment

Keep the 404 fallback in the HTTP client and the broader optional-info fallback in the desktop view model. This matches existing optional-info handling elsewhere without making metadata a prerequisite for editing config; fetching the two resources sequentially would add latency without improving that boundary.

Files changed (2) +22 / -2

Bug fix (2) +22 / -2

SingleCameraPageViewModel.csPreserve desktop config when optional info fails +15/-2

Preserve desktop config when optional info fails

• Awaits the config independently of the info request. If info fails while the caller has not requested cancellation, it logs the failure and supplies empty metadata instead of hiding the editable config.

src/OpenIPC.Viewer.App/ViewModels/SingleCameraPageViewModel.cs

MajesticHttpClient.csTreat info.json 404 as unavailable metadata +7/-0

Treat info.json 404 as unavailable metadata

• Returns an empty MajesticInfo when info.json responds with 404, matching the existing fallback for a non-JSON response. Other HTTP errors retain their existing behavior.

src/OpenIPC.Viewer.Devices/Majestic/MajesticHttpClient.cs

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

1. Info failures go unobserved after config fails 🐞 Bug ☼ Reliability

Description

GetMajesticStateAsync starts infoTask but awaits cfgTask before reaching the only await of
infoTask. If config fails or is canceled first and the info request also faults, the method exits
without observing that second exception, while its caller logs only the config failure.

Code

src/OpenIPC.Viewer.App/ViewModels/SingleCameraPageViewModel.cs[1251]

+        var config = await cfgTask.ConfigureAwait(false);

Evidence

Both HTTP operations can fault independently; after the new config await throws, control never
reaches the info await or its handler. The caller catches the propagated exception but has no
reference to the info task.

src/OpenIPC.Viewer.App/ViewModels/SingleCameraPageViewModel.cs[1247-1265]
src/OpenIPC.Viewer.App/ViewModels/SingleCameraPageViewModel.cs[817-828]
src/OpenIPC.Viewer.Devices/Majestic/MajesticHttpClient.cs[96-115]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The info request starts concurrently with config, but a config failure exits before the info task is observed.

## Fix Focus Areas
- src/OpenIPC.Viewer.App/ViewModels/SingleCameraPageViewModel.cs[1249-1265]

## Recommended Fix
Ensure the info task's completion or exception is observed even when the config await fails, without replacing the config error or making an info failure hide a valid config.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Tickets: 🎫 Majestic setting 404 error

Review mode: Auto: ⚖️ Balanced: Behavioral error-handling changes affect configuration loading and cancellation semantics.

Tip of the day

💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Info failures go unobserved after config fails 🐞 Bug ☼ Reliability

GetMajesticStateAsync starts infoTask but awaits cfgTask before reaching the only await of
infoTask. If config fails or is canceled first and the info request also faults, the method exits
without observing that second exception, while its caller logs only the config failure.

Agent Prompt

## Issue description
The info request starts concurrently with config, but a config failure exits before the info task is observed.

## Fix Focus Areas
- src/OpenIPC.Viewer.App/ViewModels/SingleCameraPageViewModel.cs[1249-1265]

## Recommended Fix
Ensure the info task's completion or exception is observed even when the config await fails, without replacing the config error or making an info failure hide a valid config.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools