Repository navigation
v2.6.1: single scheduler, live options reload, visible failures, ut1 backoff - #2
Merged
Merged
Conversation
…backoff Runtime fixes from the code review. Unlike 2.6.0.7 this changes observable behaviour (see CHANGELOG "Hinweis"). sensor.py - should_poll returned True, so HA polled every entity every 30 s on top of the plugin's own timer: hourly calendars recomputed every 30 s, and sync update() could run concurrently in two executor threads on the same instance. should_poll is now False; the timer is the only scheduler. A tick is skipped while the previous one is still running. - _async_timer_tick: first failure of a streak -> WARNING (traceback at DEBUG), further consecutive failures -> DEBUG, recovery -> INFO. After 3 consecutive failures the entity is marked unavailable via _attr_available (the hard-coded `available -> True` override is gone; HA's Entity.available is inherited). No state write when hass is None. - forget_config_entry(): _CONFIG_ENTRIES was never emptied. __init__.py - Register entry.add_update_listener -> async_reload; options saved under "Configure" now apply immediately instead of after a restart. - Let async_forward_entry_setups failures propagate instead of the broad except that returned False and hid the cause. - Remove async_reload_entry: bypassed HA's entry state machine, no callers. config_flow.py - OptionsFlow passes entry.options through unchanged on finish so the data write (which already fires the listener) is the only reload. calendars/ut1.py - Use HA's shared aiohttp session (async_get_clientsession) instead of a new ClientSession per fetch. - Exponential backoff after a failed IERS fetch: 60 s doubling to a 3600 s cap. Previously the 1-second update retried (10 s timeout, serialised by the lock) and logged a WARNING every second while the API was down. WARNING once per streak and once per hour at the cap; INFO on recovery. Verified locally with a stubbed-HA unit test (33 assertions): warn-once, unavailable-after-3, recovery, skip-if-busy, no-write-after-removal, ut1 backoff growth/cap/no-refetch/recovery/HTTP-error; plus the discovery smoke test from 2.6.0.7 (45 calendars, all importable). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
1 participant
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
Runtime fixes from the full code review (items #5, #6, #8, #10). This changes observable behaviour — please test in a live instance before it is tagged.
should_pollreturnedTrue, so HA polled every sensor every 30 s on top of the plugin timer. NowFalse; a tick is skipped while the previous one still runs.sensor.pyupdate_listenerwas registered. Now the entry reloads automatically. The options flow passesentry.optionsthrough unchanged so only one reload fires.__init__.py,config_flow.pyupdate()calls were logged at DEBUG only and the state went stale silently. Now: first failure of a streak → WARNING, further → DEBUG, recovery → INFO; entity becomesunavailableafter 3 consecutive failures.sensor.pyut1retried the IERS API every second (10 s timeout each, WARNING each time) while it was down, with a newClientSessionper call. Now HA's shared session + exponential backoff 60 s → 1 h cap, warn once per streak.calendars/ut1.py_CONFIG_ENTRIEScleaned on unload; broadexceptinasync_setup_entryremoved (errors propagate to HA); deadasync_reload_entryremoved.sensor.py,__init__.pyBehaviour changes users may notice
last_updatedonly hourly, not every 30 s.Test plan
python -m py_compile+ruff check --select E,F,W,I --ignore E501on all touched filesshould_pollFalse; warn-once / unavailable-after-3 / recovery / counter reset; skip-if-busy with an overlapping slow update; no state write after removal; ut1 backoff 60→120→…→3600 cap, no network call during backoff, recovery resets, HTTP 500 counts as failurelast_updatedin Developer Tools → States: should no longer bump every 30 sgrep -c "Updated German Rescue DTG" home-assistant.logover a fixed window: roughly 1/s, not ~1.03/s (the old 30-s platform poll on top)custom_components.alternative_timeWARNING/ERRORInstalling the branch for testing
then restart HA. (HACS cannot install a branch while the repo has releases.)
Tag
v2.6.1+ release follow after the live check.🤖 Generated with Claude Code