maziggy 84cd400685 Say why a preset's values are unavailable, not just that they are ...

The settings panel collapsed four causes into one message -- "the picked
    preset's own values could not be read" -- with no indication of what to do
    about it.

    The overwhelmingly common cause has an obvious fix, and it isn't an edge
    case: an install pulls its sidecar as SIDECAR_TAG:-latest regardless of
    which Bambuddy channel it is on, so a current Bambuddy talking to a
    sidecar that predates POST /profiles/resolve is the normal state, not a
    misconfiguration. Those users would have seen an amber warning on every
    slice with nothing pointing at the sidecar image.

    resolve_profile now returns ResolvedProfile(values, reason) instead of
    None for everything, the route passes the reason through, and the panel
    picks its message from it:

      sidecar_outdated     -> name the fix: update the sidecar image
      sidecar_unavailable  -> the sidecar did not answer
      not_configured       -> no sidecar is configured
      preset_unresolved    -> the previous generic wording

    A request that fails outright maps to sidecar_unavailable, since a
    backend we cannot reach and a sidecar that will not answer are the same
    thing from the dialog.

    Every variant still ends with "anything you don't change still uses the
    preset" -- that reassurance is the point of the notice, and it is true
    whichever way the lookup failed.

    Tests pin the distinction rather than just the happy path: a 404 and a
    500 must produce different reasons, and each panel case asserts both that
    its own message appears and that the "update the sidecar image" line does
    not leak into the others.

2026-08-15 14:48:13 +02:00

..

app

Say why a preset's values are unavailable, not just that they are

2026-08-15 14:48:13 +02:00

tests

Explain Bambu Cloud's CAPTCHA challenge instead of repeating it (#2790)

2026-08-15 14:42:27 +02:00

__init__.py

…