2 Commits

Include renames

Author	SHA1	Message	Date
maziggy	f3b1c59169	fix(orca-cloud): close the HTTP client when an authenticated build fails ... OrcaCloudService owns an httpx client from construction, and every path in _build_authenticated_service after that point can raise: no stored refresh token, a rejected refresh, an unreachable Orca, and the token-rotation write. On success the caller closes the client. On failure nobody is ever handed it, so all four paths leaked one into the connection pool. That went unnoticed while the only callers were routes, where the trigger is a person retrying a broken sign-in a handful of times. It stopped being harmless in 9434875f, which added a caller in spool assignment -- one build per Orca-referenced spool, failing on every assignment for as long as the stored credentials cannot be refreshed. The unwind guard catches BaseException rather than Exception: a cancelled request leaks the client just as surely as a failed refresh, and cancellation during shutdown is exactly when dangling sockets are least welcome. The close inside it is guarded in turn, so a failing cleanup cannot replace the error the caller needs to see -- least of all a CancelledError, which has to keep propagating for cancellation to work at all. Six tests. Four fail against the unguarded builder, verified by reverting the guard and re-running; the other two pin the surrounding contract (a failing close must not mask the real error, and a successful build must leave the client open for its caller) and pass either way. The shared _expired_service helper now gives the mock an awaitable close(), so the four pre-existing refresh tests exercise the same path. Also corrects two comments and the changelog entry from 9434875f, which overstated what the captures support. They claimed Bambu Cloud returns a preset's filament_id in either of two places and only one was read. The responses recorded in #1053 show something narrower: a Studio-created preset carries it on the envelope, and an Orca-created one has none at all -- the envelope says null and `setting` is a delta from the base. The `setting` lookup stays as belt-and-braces for a shape no captured response has needed yet, but it is not why a custom profile reached the slicer as its base. That is the OrcaSlicer preset format having no filament_id field, filed upstream as OrcaSlicer PR #13315. The eight-character truncation is now evidenced across three models rather than one -- an A1 storing PFUS9DDC of PFUS9DDC938FE3AB8F, a P1S storing PFUS7A65 of PFUS7A65290D3DADC4, and an H2D storing 8219C45D of an Orca profile UUID.	2026-09-07 10:39:10 +02:00
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