Release v2.6.1 - #14
Conversation
…tion On real appliances the program option list is built from a list of program names, so the lookup map is keyed by name (name->name) and a numeric prCode can never match it. current_option tried the numeric settings.prCode/prCode keys before startProgram.program, which still resolved correctly via the fallback chain but logged a misleading 'non mappato' DEBUG line on every poll (hundreds per hour on washer+dryer). Reorder the key list so the name-yielding keys (programName, settings.program, startProgram.program, program) are tried before the numeric prCode keys. current_option now resolves on the first mappable name and no longer emits spurious 'non mappato' noise for codes that were never mappable. Behaviour for code->name maps (numeric prCode genuinely in the map) is unchanged: the prCode keys are still tried, just last. Add a regression test reproducing the production case (name-keyed map, device exposing an unmappable numeric prCode plus the name via startProgram.program) asserting current_option returns the name without logging 'non mappato'.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthrough
ChangesProgram select key priority fix
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
…t refresh Audit findings #1 (HIGH) and #14, plus the concurrent-refresh race. _check_headers refreshed the OAuth token before EVERY request whenever a refresh_token was present (#1): with several appliances and the asyncio.gather in load_commands, that is dozens of POST /services/oauth2/token per coordinator cycle (token is valid 8h), risking cloud rate-limit/block. A single 401 also cascaded into 3 refreshes (#14: pre-refresh + loop0 + recursion). Refresh only when there is no usable in-RAM token (first request / restart with a persisted refresh_token) or the token is near expiry; the 401 recovery in _intercept is unchanged, and since refresh() resets _expires the recursive _check_headers no longer fires a second time. An asyncio.Lock (on the connection, not the create()-replaced HonAuth) with a re-check collapses a concurrent burst into a single refresh, so a rotating IdP cannot invalidate the shared token mid-flight. Tests: no pre-refresh when fresh (#1), single refresh on 401 (#14), refresh on expires-soon, restart-with-token refreshes not logins, concurrent burst -> 1 refresh (lock).
…t refresh Audit findings #1 (HIGH) and #14, plus the concurrent-refresh race. _check_headers refreshed the OAuth token before EVERY request whenever a refresh_token was present (#1): with several appliances and the asyncio.gather in load_commands, that is dozens of POST /services/oauth2/token per coordinator cycle (token is valid 8h), risking cloud rate-limit/block. A single 401 also cascaded into 3 refreshes (#14: pre-refresh + loop0 + recursion). Refresh only when there is no usable in-RAM token (first request / restart with a persisted refresh_token) or the token is near expiry; the 401 recovery in _intercept is unchanged, and since refresh() resets _expires the recursive _check_headers no longer fires a second time. An asyncio.Lock (on the connection, not the create()-replaced HonAuth) with a re-check collapses a concurrent burst into a single refresh, so a rotating IdP cannot invalidate the shared token mid-flight. Tests: no pre-refresh when fresh (#1), single refresh on 401 (#14), refresh on expires-soon, restart-with-token refreshes not logins, concurrent burst -> 1 refresh (lock).
…t refresh Audit findings #1 (HIGH) and #14, plus the concurrent-refresh race. _check_headers refreshed the OAuth token before EVERY request whenever a refresh_token was present (#1): with several appliances and the asyncio.gather in load_commands, that is dozens of POST /services/oauth2/token per coordinator cycle (token is valid 8h), risking cloud rate-limit/block. A single 401 also cascaded into 3 refreshes (#14: pre-refresh + loop0 + recursion). Refresh only when there is no usable in-RAM token (first request / restart with a persisted refresh_token) or the token is near expiry; the 401 recovery in _intercept is unchanged, and since refresh() resets _expires the recursive _check_headers no longer fires a second time. An asyncio.Lock (on the connection, not the create()-replaced HonAuth) with a re-check collapses a concurrent burst into a single refresh, so a rotating IdP cannot invalidate the shared token mid-flight. Tests: no pre-refresh when fresh (#1), single refresh on 401 (#14), refresh on expires-soon, restart-with-token refreshes not logins, concurrent burst -> 1 refresh (lock).
Automated release PR for
v2.6.1.Summary by CodeRabbit
Bug Fixes
Tests