fix(fox): bump settings cache version to force-refresh fdpwr_max on upgrade - #4532
Merged
Conversation
…pgrade battery_rate_max is only recomputed when get_scheduler() actually makes a live call, which is otherwise gated to once an hour - so a customer upgrading to the capacity_watts() fix kept the old, wrongly-clamped fdpwr_max from their persisted cache while inverter_capacity (recomputed live every publish cycle from cached device_detail) updated immediately. Bumping FOX_SETTINGS_CACHE_VERSION triggers the existing self-heal path that forces one scheduler refresh regardless of cache age.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR forces a one-time refresh of Fox scheduler-derived settings after upgrade by bumping FOX_SETTINGS_CACHE_VERSION, ensuring fdpwr_max (battery rate max) is recomputed immediately rather than potentially lingering from persisted scheduler_state cache for up to FOX_REFRESH_SETTINGS (60 minutes).
Changes:
- Bump
FOX_SETTINGS_CACHE_VERSIONfrom 2 → 3 to invalidate persisted Fox settings/scheduler cache and trigger the existing self-heal refresh path.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
battery_rate_max(fdpwr_max) is only recomputed whenget_scheduler()makes a live API call, gated to once an hour byFOX_REFRESH_SETTINGS- otherwise it's restored as-is from the persistedscheduler_statecache. That meant a customer upgrading to the fix(fox): correct half-kW inverter capacity and round noisy production totals #4527 fix kept the old, wrongly-clampedfdpwr_max(e.g. 10000W on a 10.5kW inverter) for up to an hour after upgrading, whileinverter_capacity/inverter_limit(recomputed live every publish cycle straight from cacheddevice_detail) updated immediately - producing a confusing mismatch between the two ("AC limit 10.5kW" vs "battery rate raw 10000.0W" in the log).FOX_SETTINGS_CACHE_VERSION, which triggers the existing self-heal path (added for exactly this kind of derivation change) that forces one scheduler refresh regardless of cache age.Test plan
./run_all --test fox_apipasses./run_pre_commitpasses (ruff, black, cspell, docstrings, full test suite)🤖 Generated with Claude Code