Summary
Grab-bag of small backend correctness issues:
PUT /system/power-profile returns HTTP 200 on failure (system.py:62-65) - returns StatusResponse(success=ok, ...) where every sibling mutating endpoint raises HTTPException(500). A client keying on HTTP status treats a failed change as success.flatpak list subprocess calls have no timeout (protontricks.py:122-128, 154-159) - every other subprocess call passes timeout=; these two do not, so a stalled flatpak (bus/portal hang) blocks the handler forever.set_launch_options writes lowercase "apps" while the reader accepts "Apps" (vdf_config.py:20 vs 115) - on an older-client file using "Apps", the write creates a second parallel block; set_compat_tool L94 similarly can serialize the mapping twice.
Fix
Raise on power-profile failure; add timeout= to the flatpak calls; make the apps-node read/write use a single canonical key.
Summary
Grab-bag of small backend correctness issues:
PUT /system/power-profilereturns HTTP 200 on failure (system.py:62-65) - returnsStatusResponse(success=ok, ...)where every sibling mutating endpoint raisesHTTPException(500). A client keying on HTTP status treats a failed change as success.flatpak listsubprocess calls have no timeout (protontricks.py:122-128, 154-159) - every other subprocess call passestimeout=; these two do not, so a stalled flatpak (bus/portal hang) blocks the handler forever.set_launch_optionswrites lowercase"apps"while the reader accepts"Apps"(vdf_config.py:20 vs 115) - on an older-client file using"Apps", the write creates a second parallel block;set_compat_toolL94 similarly can serialize the mapping twice.Fix
Raise on power-profile failure; add
timeout=to the flatpak calls; make the apps-node read/write use a single canonical key.