1 commit

Author	SHA1	Message	Date
maziggy	455a9e4ba7	fix(backup): collect cloud profiles from every connected account (#2717) ... Enabling Cloud Profiles for a Git backup produced nothing, and said it had worked. Two independent faults, either one sufficient. The collector looked for a "setting" list. The Bambu Cloud listing endpoint is keyed by preset type instead, each key holding private and public arrays, so the loop body never executed once — and the entries carry no type of their own either, which routes/cloud.py already knew: it takes the type from the outer key and maps Bambu's "print" to process. Two bugs on one line. It also asked build_authenticated_cloud for the credential store used when authentication is disabled. With auth on, tokens live on User rows, so the collector returned at "Cloud not authenticated" before ever reaching the bad key. Every multi-user install was collecting from zero accounts. Neither failure surfaced. backup_metadata.json recorded the configured flag rather than the outcome, so it claimed cloud_profiles: true on runs that wrote nothing, and the log read "Collected cloud profiles: 0 filament, 0 printer, 0 process" at INFO — which is exactly what a successful backup of an empty account looks like. Cloud profiles now come from every connected account across both clouds. The toggle predates Orca Cloud entirely, and Orca has the same three preset types, so both are collected and grouped the same way: cloud_profiles/bambu/user-3/{filament,printer,process}.json cloud_profiles/orca/user-3/{filament,printer,process}.json Accounts are keyed by Bambuddy user id, "global" when auth is off. Never by email: a backup repository can be public, and the Bambu listing's user_id is dropped for the same reason. Both credential stores are read on every run, because a Settings row survives someone enabling auth later and dropping it would silently stop backing that account up. Bambu costs one get_setting_detail per private preset. The listing is metadata only, and without base_id and setting the backup is a list of names that create_setting cannot rebuild from. Public presets are skipped — Bambu's bundled catalogue is the same hundreds of entries for everyone, always re-downloadable, not recreatable under your account, and would rewrite the repository on every run. Orca needs no second call; its sync-pull carries each profile's content inline. Where the Orca route drops a profile whose content.type it cannot map, the backup writes it to other.json instead: silently omitting a profile because Orca added a type is the same class of bug as this one. Failures are contained per account and per preset, and counted rather than swallowed. A partial backup that looks complete is how this stayed invisible. The metadata now reports what was collected, per cloud and per account, and a run that collects nothing while the category is enabled warns with the reason instead of an INFO line that reads like success. The checkbox gated on the viewer's own Bambu sign-in, which is not the same question as whether there is anything to back up — with auth enabled the accounts belong to individual users, and an administrator who never signed in personally saw the category disabled with plenty in scope. It now gates on the total across both clouds and shows the counts. That comes from its own endpoint rather than a field on /config, since /config answers null until the first save and would disable the toggle during the very setup it belongs to. Counts only, never identities. One deliberate restraint. _build_authenticated_service clears stored credentials when a refresh is rejected, which is right for a route — the user is on the page and can pair again — and wrong for a scheduled job. Orca reports every rejection with one composite reason ("unknown, expired, revoked, or already used"), so a genuine revocation cannot be told apart from a lost token-rotation race, and acting destructively on a signal that cannot be disambiguated is the #2562 mistake in a different cloud. It also gains nothing: the Profiles route hits the same failure and clears it then, with the user present. Background callers now pass clear_on_auth_failure= False and skip the account. A successful refresh is still persisted either way — by that point the old token is consumed, so dropping the new pair would break a working pairing for real. Restore is not part of this. Nothing reads cloud_profiles/* yet; the format carries base_id/setting for Bambu and content for Orca so that it can.	2026-07-31 16:59:33 +02:00